DE102009011156B4 - Device for controlling and regulating a drive system - Google Patents

Abstract

A device for controlling and regulating a drive system, which comprises a computer program code, the computer program code being structured in several blocks, the blocks including functions for controlling and regulating the drive system as delimitable components of the computer program code, the device comprising at least one hardware-specific sensor interface, The sensor interface is assigned functions for basic processing of the raw sensor signals sent by sensors to the device for controlling and regulating the drive system, the sensor interface being structured by two layers, with a hardware access layer being on the lowest level a sensor signal conversion layer is located above the hardware access layer, the hardware access layer and the sensor signal conversion layer being separated from one another by a runtime environment, the hardware access layer for each includes individual sensor functions for controlling hardware modules for the acquisition of electrical signals, the sensor signal conversion layer for each individual sensor including functions for converting the electrical signals into physical quantities, the sensor interface with an observer for correcting / adapting the with the device sensors connected to control and regulate the drive system interacts, the observer being assigned functions that correct / adapt the signals of the sensors as a function of the signals from other sensors and / or models, the sensor interface being equipped with a diagnostic tool in addition to the observer. Manager, interacts with a diagnosis function and a reconfigurator, the results of the hardware diagnosis and the electrical diagnosis of the sensor interface being passed on to the diagnosis manager, the diagnosis manager still receiving results of the diagnosis function, wherein the results of the diagnostic function are calculated from residuals that were determined by means of the observer, with a switch to a substitute or model value in the observer being carried out if necessary using a decision strategy via the reconfigurator.

Description

The present invention relates to a device for controlling and regulating a drive system according to the features of the patent claims.

From the DE 100 44 319 A1 It is previously known to use embedded software solutions to control and / or regulate a vehicle, so-called basic functions and operating functions being used, the basic functions including so-called core functions and driver software, i.e. functions that are control unit-specific, the operating functions including functions, which determine the actual operating behavior of the vehicle, the basic functions and the operating functions being separated from one another in such a way that operating functions can be added or replaced without the basic functions having to be changed. However, if there is a change in the sensor system, for example as part of a further development of the drive system of a motor vehicle, it can be assumed that both changes in the operating functions and changes in the basic functions are required.

According to US 2008/0 188 963 A1, an object-oriented control system for a device is previously known, configurable by a configuration mechanism in selectively operable communication with a multiplicity of object-oriented control systems using a packet protocol for the construction of messages which include identifiers from a multiplicity of name spaces, which are connected to the building blocks of the object-oriented systems.

From the DE 699 33 895 T2 For example, a viewing process function module is previously known that is implemented in a process control device and can be used in a process control network having a plurality of devices communicatively coupled to a bus. Furthermore, each of the devices has one or more process function modules which are capable of performing an input function, an output function or a control function in the process control network and which are capable of communicating on the bus using scheduled periodic communications. The viewing process function module has the following: a data acquisition unit that receives a multiplicity of input signals that contain values of at least one process parameter. These input signals are generated by a plurality of the process function modules in one or more facilities and are transmitted using the scheduled periodic communications.

task

It is therefore the object of the present invention to provide a device for controlling and regulating a drive system, the need for changes as little as possible when the drive system is changed or the sensor system is changed.

solution

According to the invention, this object is achieved by means of a device for controlling and regulating a drive system which comprises a computer program code, the computer program code being structured in several blocks, the blocks including functions for controlling and regulating a drive system as delimitable components of the computer program code, the device being a Sensor interface comprises which functions for basic processing of the raw sensor signals sent to the device for controlling and regulating a drive system of sensors are assigned, the sensor interface being structured by two layers, with a hardware access layer being located on the lowest level, with a sensor signal conversion layer is located above the hardware access layer, the hardware access layer and the sensor signal conversion layer being separated from one another by a runtime environment, the hardware access layer for each individual sensor includes functions for controlling hardware components for the acquisition of electrical signals, the sensor signal conversion layer for each individual sensor including functions for converting the electrical signals into physical quantities. By separating the sensor interface into two layers according to the invention, the advantage is achieved that the functions assigned to the respective layer can be developed and programmed by the competent side. Since the know-how on sensors is practically always on the side of a system manufacturer or supplier and the know-how for the application-oriented use or the further processing of the sensor signals adapted to the respective use as well as legally compliant monitoring of the components of a mechatronic system at the respective manufacturer of the drive system As is the case with a vehicle manufacturer (OEM), for example, the separation of the layers according to the invention makes it possible for both system manufacturers and OEMs to be able to specifically contribute their competencies as part of a development process that takes place in parallel. In one embodiment of the present invention, there are no cross-couplings between the individual functions of the hardware access layer and between the individual functions of the sensor signal Conversion layer no cross-coupling. Due to the layered structure of the sensor interface, a simple adaptation of the software of an underlying device for controlling and regulating a drive system when changing the sensor system is advantageously possible, since there are no cross-couplings between the individual functions of the respective layer of the sensor interface. If, for example, the sensor from one manufacturer is replaced by a sensor from another manufacturer, then only the function assigned to the respective layer is affected and not the functions that are provided in the respective layer for the remaining sensors. The functions assigned to the hardware access layer preferably include hardware-specific drivers for each sensor for reading out the input interfaces, such as, for example, drivers for accessing digital and analog converters of the hardware used in the underlying device for controlling and regulating a drive system. In addition, the hardware access layer for each sensor includes functions for diagnosing the status of the respective connected sensors or the hardware, so that hardware-related status information is available. Functions for carrying out electrical diagnoses are also assigned to the sensor signal conversion layer. These electrical diagnoses include, for example, a signal range check. If redundant sensor information is available for a measured value, for example for the throttle valve opening angle from two position sensors, mutual plausibility checks of the sensor signals can also be carried out using the functions assigned to the sensor signal conversion layer for performing electrical diagnoses in order to then provide a single physical value.

The sensor interface interacts with an observer to correct / adapt the sensors connected to the device for controlling and regulating a drive system, the observer being assigned functions that correct / adapt the signals as a function of the signals from other sensors and / or models the sensors.

In addition to the observer, the sensor interface interacts with a diagnosis manager, a diagnosis function and a reconfigurator, the results of the hardware diagnosis and the electrical diagnosis of the sensor interface being passed on to the diagnosis manager, the diagnosis manager continues to receive results of the diagnostic function, the results of the diagnostic function being calculated from residuals that were determined by means of the observer, a switch to a substitute or model value in the observer being carried out using a decision strategy via the reconfigurator, if necessary.

1. a.) eine Sensor-Schnittstelle,
2. b.) eine Aktuator-Schnittstelle,
3. c.) eine Kommunikations-Schnittstelle,
4. d.) einen Beobachter/eine Signalverarbeitung,
5. e.) einen Diagnose-Manager,
6. f.) einen Rekonfigurator,
7. g.) eine Diagnosefunktion,
8. h.) einen Controller,

vorgesehen ist, wobei die Blöcke a.) bis h.) zum Austausch von Daten/Informationen miteinander verbunden sind, wobei den Blöcken a.) bis h.) Funktionen zugeordnet werden, wobei in Abhängigkeit des Antriebskonzeptes des zu Grunde liegenden Antriebssystems und/oder der Anzahl/Eigenschaften der verwendeten Sensoren oder Aktoren die den Blöcken a.) bis h.) zugeordneten Funktionen festgelegt werden. Mit anderen Worten dienen die Blöcke a.) bis h.) als Behälter oder Container für die zur Steuerung und Regelung des Antriebssystems notwendigen Funktionen, wobei der Inhalt der Container je nach Antriebskonzept des zu Grunde liegenden Antriebssystems, also im Rahmen einer Fahrzeuganwendung, beispielsweise einem Otto-, Diesel- oder Hybridantrieb und/oder der Anzahl/Eigenschaften der verwendeten Sensoren oder Aktoren, variiert. Vorteilhaft wird demgemäß durch die Anordnung und Verbindung der Blöcke a.) bis h.) eine allgemein gehaltene modulare Gesamtstruktur gebildet, mit der sich verschiedene Antriebskonzepte, also beispielsweise ein Otto-, Diesel- oder Hybridantrieb eines Fahrzeuges, steuern und/oder regeln lassen, wobei die Blöcke a.) bis h.) als Container für die notwendigen Funktionen agieren, wobei je nach Antriebskonzept der Inhalt der Container variiert. Ein Antriebssystem kann im Sinne der vorliegenden Erfindung u. a. eine Verbrennungskraftmaschine, eine Kopplung einer Verbrennungskraftmaschine mit einem Getriebe zum Antrieb eines Fahrzeuges, eine Kopplung einer Verbrennungskraftmaschine mit einem Generatorsystem zur Gewinnung elektrischer Energie oder auch der Oberbegriff für den gesamten Antriebsstrang eines Fahrzeuges sein. Unter einem Block wird ein übergeordnetes Architektur- oder Strukturelement verstanden, das als Behälter für Module und Funktionen dient. Als Funktion werden elementare, abgrenzbare Bestandteile der Steuerung und Regelung beziehungsweise einer Software zur Steuerung und Regelung bezeichnet, die eine definierte Aufgabe erfüllen und genau spezifizierte Schnittstellen aufweisen. Beispielsweise handelt es sich bei einem so genannten Leerlaufregler einer Verbrennungskraftmaschine als Antriebssystem eines Kraftfahrzeuges um eine Funktion. Ein Modul bezeichnet weiterhin eine Menge von thematisch zusammengehörigen Funktionen. So enthält beispielsweise das Modul „Triebstrangkoordinator“ sämtliche zur Steuerung und Regelung des Antriebsstranges eines Kraftfahrzeuges, u. a. bestehend aus einer Verbrennungskraftmaschine und einem Getriebe, notwendigen Funktionen. Soweit technisch möglich, entspricht ein Modul einer physikalisch beschreibbaren Hardwarekomponente, beispielsweise dem Luftsystem oder dem Kraftstoffsystem einer Verbrennungskraftmaschine.In particular, the sensor interface is part of a modular structure formed from several blocks for controlling and regulating a drive system, with at least one block for each

1. a.) a sensor interface,
2. b.) an actuator interface,
3. c.) a communication interface,
4. d.) an observer / signal processing,
5. e.) a diagnosis manager,
6. f.) a reconfigurator,
7. g.) a diagnostic function,
8. h.) a controller,

is provided, the blocks a.) to h.) being interconnected for the exchange of data / information, the blocks a.) to h.) being assigned functions, depending on the drive concept of the underlying drive system and / or the number / properties of the sensors or actuators used and the functions assigned to blocks a.) to h.). In other words, the blocks a.) To h.) Serve as a container or container for the functions necessary for controlling and regulating the drive system, the contents of the container depending on the drive concept of the drive system on which it is based, i.e. within the scope of a vehicle application, for example a Otto, diesel or hybrid drive and / or the number / properties of the sensors or actuators used varies. Accordingly, the arrangement and connection of the blocks a.) To h.) Advantageously form a general modular overall structure with which various drive concepts, for example a gasoline, diesel or hybrid drive of a vehicle, can be controlled and / or regulated, where the blocks a.) to h.) act as a container for the necessary functions, the content of the container varies depending on the drive concept. A drive system in the sense of the present invention can include an internal combustion engine, a coupling of an internal combustion engine with a transmission for driving a vehicle, a coupling of an internal combustion engine with a generator system for generating electrical energy or the generic term for the entire drive train of a vehicle. A block is understood to be a higher-level architectural or structural element that serves as a container for modules and functions. A function is the term used to describe elementary, definable components of control and regulation or software for control and regulation, which fulfill a defined task and have precisely specified interfaces. For example, what is known as an idling controller of an internal combustion engine as a drive system of a motor vehicle is a function. A module also describes a number of thematically related functions. For example, the “Drivetrain Coordinator” module contains all the functions required to control and regulate the drive train of a motor vehicle, including an internal combustion engine and a transmission. As far as technically possible, a module corresponds to a physically writable hardware component, for example the air system or the fuel system of an internal combustion engine.

The sensor interface, or the functions assigned to the sensor interface, as well as the modular structure of the blocks a.) To h.) Is / are designed in particular as computer program code, which is stored and executed on a generally known control unit of a drive concept will.

Embodiment

Further advantageous refinements of the present invention can be found in the following exemplary embodiment and in the dependent claims.

• 1: die modulare Struktur zur Steuerung und Regelung eines Antriebssystems,
• 2: die modulare Struktur als Bestandteil einer Vorrichtung zur Steuerung und Regelung eines Antriebssystems aus AUTOSAR-Sicht,
• 3: Details der Sensor-Schnittstelle,
• 4: die Darstellung des Signalflusses von einem gewandelten Sensorspannungswert bis zum Istwert,
• 5: Details der Aktuator-Schnittstelle,
• 6: Details zur Signalaufbereitung,
• 7: das Prinzip eines Zustandsbeobachters,
• 8: Details zum Beobachter/zur Signalverarbeitung,
• 9: Details zur Kommunikation innerhalb des Beobachters/der Signalverarbeitung,
• 10: Details zu einer Signalauswahl,
• 11: Details des Diagnose-Managers,
• 12: interne Kommunikation/Signalfluss innerhalb des Diagnose-Managers,
• 13: den Signalfluss innerhalb des Controllers,
• 14: Details zur Diagnosefunktion,
• 15: die zusätzliche Modulebene in der Diagnosefunktion,
• 16: die Kommunikation innerhalb der Diagnosefunktion,
• 17: Details zum Rekonfigurator,
• 18: Details zu Rekonfigurationsstrategien.

Here show:

• 1 : the modular structure for controlling and regulating a drive system,
• 2 : the modular structure as part of a device for controlling and regulating a drive system from an AUTOSAR perspective,
• 3 : Details of the sensor interface,
• 4th : the representation of the signal flow from a converted sensor voltage value to the actual value,
• 5 : Details of the actuator interface,
• 6th : Details on signal processing,
• 7th : the principle of a condition observer,
• 8th : Details about the observer / signal processing,
• 9 : Details on communication within the observer / signal processing,
• 10 : Details of a signal selection,
• 11 : Details of the diagnosis manager,
• 12th : internal communication / signal flow within the diagnostic manager,
• 13th : the signal flow within the controller,
• 14th : Details on the diagnostic function,
• 15th : the additional module level in the diagnostic function,
• 16 : the communication within the diagnostic function,
• 17th : Details about the reconfigurator,
• 18th : Details on reconfiguration strategies.

According to 1 shows the modular structure for controlling and regulating a drive system that comprises blocks a.) to h.) and further blocks i.) to l.). The block a.) Represents a sensor interface in the structure that is responsible for the basic processing of sensor signals, with functions assigned to the block a.) Serving to control hardware modules for the acquisition of signals, for example a To carry out A / D conversion, to convert electrical signals into physical quantities, for example to convert a voltage into a pressure, and to carry out a hardware-related basic diagnosis and plausibility check of the measured signals. The functions assigned to block a.) Are hardware-related and serve as a kind of hardware abstraction layer. The block a.) Is connected to sensors for the exchange of information / data as well as to the block d.), That is to say the observer or the signal processing, as indicated by the two arrows in bold. Input variables of block a.) Are the scanned, quantized electrical signals of the sensors, which are processed by the functions assigned to block a.), So that the output variables of block a.) Are converted into physical variables, such as pressure or temperature , converted electrical sensor signals which are fed to block d.), with the observer / signal processing unit being able to correct / adapt the detected signal or compare it with modeled signal values. In addition, the block a.) For the exchange of information / data is connected to the block e.), I.e. the diagnosis manager, as indicated by the arrow, whereby depending on the result of the basic diagnosis and plausibility check carried out in block a.) Measured signals by means of the diagnosis manager in block e.) management takes place, for example a filing of error information in a non-volatile memory and, if necessary, to the outside via a diagnosis tester. In practice, the provision of block a.) In conjunction with blocks d.) And e.) Has the advantage that if a sensor from a certain manufacturer is exchanged for a sensor from another manufacturer, only block a.), That is the sensor interface and no other features of the device for controlling and regulating the Drive system are influenced, so remain unchanged.

The block b.) Represents the actuator interface in the structure, which is responsible for the final processing of control signals and their forwarding to the actuators or output stages. In addition to the respective actuators, block b.) Is connected to block h.), I.e. the controller, for the exchange of data / information, as indicated by the bold arrow. In block b.), Control signals are read that can be present in logical or physical units and that are formed in block h.). The functions assigned to block b.) Convert these control signals into signals in a suitable form so that they can be passed on to output stages for controlling the actuators, as indicated by the further bold arrow. The functions assigned to block b.) Mainly have the task of final processing of control signals, of creating a driver for the output stage hardware, of creating a driver for actuator hardware and of carrying out output stage diagnoses. The block b.) Is further connected to the exchange of information / data with the block e.), Ie the diagnosis manager, as indicated by the arrow, whereby depending on the result of the diagnoses carried out in block b.) Of the output stages or of the actuators by means of the diagnosis manager in block e.) management takes place, for example a filing of error information in a non-volatile memory and possibly communication of the error information to the outside via a diagnosis tester. In addition, the block b.) Is connected to the exchange of information / data with the block d.), I.e. the observer / the signal processing unit, as indicated by the two arrows, whereby in particular current modeled / observed process variables or measured signals from the block d .) are transmitted to block b.).

is done with the help of the division into block b.) and block h.) a decoupling of controller functions and the actuator used, or by means of the division of block h.) to which controller functions are assigned, and block b.) controller functions independent of the actuator used will be realized. An example of this is what is known as a rail pressure control for setting a specific pressure value in the rail of the injection system of an internal combustion engine. The controller function assigned to block h.) Generates a setpoint volume flow through the high-pressure pump as an abstract manipulated variable. The actuator interface, i.e. block b.), Calculates a control of the actuator from this abstract manipulated variable. The latter can be, for example, a quantity control valve or, in another concept, a suction-side three-way valve. The controller function remains independent of the pump concept and can be used for different fuel systems.

The block c.) Represents a communication interface in the structure that enables a connection with other devices for controlling and regulating a drive system, i.e. other control devices or units, which enable protocol-based communication, such as CAN, CCP, XCP, FlexRay or diagnostic tester support. The block c.) Is consequently assigned functions that carry out the exchange of data or messages with other communication partners. Furthermore, the CAN monitoring, for example with regard to timeouts, must also be accommodated here. The block c.) Is accordingly connected to external communication networks, such as the CAN bus, as indicated by the double arrow. In addition, block c.) For communication within the structure is connected to block h.), I.e. the controller, block d.), I.e. the observer / signal processing, and block e.), I.e. the diagnosis manager, such as indicated by the arrows. Via the connection of block c.) To block e.), Data / information regarding diagnostic results of other control devices or units of the drive system can also be transmitted, as indicated by the arrow / double arrow. The input variables of block c.) Can therefore be summarized as external signals, for example signals received via CAN, measured or modeled signals from block d.) That are to be sent on, control signals from block h.) That are sent to another control unit, for example and diagnostic results managed by block e.), such as error memory entries. As output variables of block c.), On the one hand, signals that are sent to the outside, such as measured / modeled signals from block d.), On the other hand, control signals from block h.) And further diagnostic results from block e .). Output signals of block c.) Are also read-in external variables, such as the raw vehicle speed or torque setpoints, which are forwarded to block d.) Via block c.).

In the structure, block d.), I.e. the observer / signal processing, represents an essential element that goes beyond the pure control-technical basic function of a condition observer. The latter is known to be characterized by a mathematical model, which receives the same input variables as the process to be observed and has the purpose of determining non-measurable state variables of the system. For this purpose, the output variables of the model are compared with the measured output variables of the process and the deviation between, known as the residual Measurement and model are used to correct the modeled state variables.

The functions that are assigned to block d.) Are used to supply block b.), Block h.) And block g.) With the required information about the actual state of the drive and vehicle; the required connections are shown as arrows in 1 shown. For the implementation of model-based diagnoses, block g.) In particular is supplied with the observer residues. The actual state is made up of measured signals, observed variables and other variables calculated from measurements, observations and the further block d.) Signals made available. These can be continuous-value signals such as rotational speeds or pressures, but also discrete-value information such as the current operating mode of an internal combustion engine or a status bit that indicates the operational readiness of a lambda probe. The definition of the actual state used here goes beyond the control-technical definition, since not only state variables are determined which describe the dynamics of the overall system, but further information is also made available to the system. An example of such information is the cylinder charge, which is calculated from state variables such as intake manifold pressure, etc.

In other words, the functions assigned to block d.) Have the task of observing the current actual state of the drive system to be controlled and regulated with the aid of models. Here, for example, simplified non-linear dynamic models are used to estimate the measurable and non-measurable state variables of the system on the basis of the control signals and the environmental conditions. In this context, modeled measurable states are compared with measurement signals. For the transmission of measurement signals, block d.) Is connected to block a.), As in FIG 1 shown. The so-called residuals emerge from this comparison, with the aid of which an observer feedback is implemented, which corrects the modeled state variables. A calculated error, for example between the model and the measurement, is referred to as a residual. If a measurable variable is calculated with the help of a mathematical model, the difference between the measured and modeled value represents the residual. Another task of the functions assigned to block d.) Is the observation of the system states, these observed states in addition can be used to use non-measurable variables in the open-loop and closed-loop control. In the event of a sensor failure, observed states can be used as substitute values for measured variables.

As already described, it is also the task of the functions assigned to block d.) To supply the functions assigned to block h.) And block g.) With information about the actual state of the system and the residuals. For this purpose, block d.) Is connected to block h.) And block g.) For the exchange of data / information, so that measured and / or modeled / observed signals can be transmitted, as in FIG 1 indicated by the arrows, wherein the measured and / or modeled / observed signals can also be combined in a common bus. Furthermore, block d.) Enables the functions that are assigned to block h.), I.e. the controller, to be implemented independently of the sensor configuration. Such a decoupling or abstraction of the sensor system has the advantageous effect that when the sensor configuration is changed, for example when the drive concept is changed, due to the defined interface between block d.) And block h.), Only the functions that are assigned to block d.) are assigned, must be changed, and not the functions assigned to block h.). A change in the sensor configuration is therefore not reflected in a change in the controller functions. In other words, according to block d.), The observer abstracts the sensors and decouples them from the regulator functions in the controller, i.e. from block h.). If, for example, the sensor configuration changes in the course of a project change, only the functions assigned to block d.) Need to be adapted. The functions that are assigned to block h.) Remain unaffected because the defined interface between block d.) And block h.) Remains unchanged. As already shown, the block d.) For the exchange of data / information is also connected to block b.), Wherein in particular modeled / observed or also measured signals are transmitted from block d.) To block b.), As by indicated by the arrows.

Another functionality of block d.) Is the implementation of model- or signal-based sensor adaptation methods, which can reduce the influence of measurement inaccuracies of the sensors. The modules and functions in block d.), I.e. the observer, can naturally be assigned to individual hardware components. In connection with an internal combustion engine that is used, there is an intake manifold model, a rail model and so on. A so-called "component view" is always retained, which allows modules and functions to be quickly assigned to hardware components of the drive system. In general, an observer-based structure has the following advantages. On the one hand, there is an improvement in the control quality. With technical systems, everything is not always measurable. For a higher-order system, the control quality can be significantly improved if the internal system states are used for the control signal generation in addition to the output feedback. An observer, as in block d.), Offers the possibility of reconstructing internal system states without additional sensors. The control quality can be improved by feeding back the observed states. All internal system states are recorded by the observer according to block d.) And are available for control. In this way, powerful modern processes, such as state controllers, can be integrated without any problems. The use of this additional information can lead to higher control quality. On the other hand, there is an improvement in the quality of the diagnosis. Thus, on the basis of an observer, as in accordance with block d.), Estimated states are compared with measured signals. If the residuals between observed and measured signals exceed previously defined threshold values during runtime, it can be concluded that there is an error. With the help of residuals and dynamic models, better diagnostic results, for example with regard to error detection, pinpointing and quantification, can be achieved. Pinpointing describes the identification of the smallest replaceable defective component in the drive system. All sensor sizes can therefore be compared with corresponding model sizes. The resulting residuals can be used for fault diagnosis. Powerful model-based diagnostic techniques can be implemented in this way. With regard to the depth of diagnosis, these methods are more meaningful than simple signal-based methods as they are currently used. Furthermore, there is an increased fault tolerance and reliability. Thus, observer functions, as in accordance with block d.), Can be viewed as virtual sensors which, in the event of a fault, supply substitute values for the failed sensors. In this way, the degree of reliability of the overall system can be increased. In addition, there is a potential for savings in sensor costs, since the observer functions, as in accordance with block d.), Can be viewed as virtual replacement sensors. For example, depending on the result of an observability analysis, it is possible to save some real sensors. However, these savings come at the expense of reliability and fault tolerance. At this point, a tradeoff should be made between fault tolerance and sensor cost. In addition, block d.) Is connected to block c.), That is to say the communication interface, for the exchange of data / information, as indicated by the double arrow. Thus, external signals, such as the raw vehicle speed, can be transmitted to block d.) Via block c.) And measured and modeled signals to be sent to the outside can be forwarded from block d.) To block c.). Furthermore, block d.) Is connected to block g.), That is to say the diagnostic function, for the exchange of data / information, as indicated by the two arrows. In this way, measured / modeled signals can be transferred from block d.) To block g.) In order to carry out an active diagnosis. In addition, block d.) Is connected to block e.) For the exchange of data / information, as indicated by the arrow / double arrow. In this way, release information or release requests, for example for model adaptation, can be transmitted to block e.). In addition, block d.) Is connected to block f.) For the exchange of data / information, as indicated by the arrow, wherein reconfiguration information from block f.) Can be transmitted to block d.), Block f.) Functions are assigned that correspond to a "reconfiguration", ie a switchover of signals, structures or parameters during runtime, which take place as a function of diagnostic results.

In the structure, block e.) Represents the diagnosis manager, to which functions are assigned which have the task of managing diagnosis results that are provided by the diagnosis function according to block g.). The detected errors are stored in the non-volatile memory and / or forwarded to the outside via a diagnostic tester via a connection with block c.). Furthermore, the release of functions depending on the diagnosis results, the administration of the workshop diagnoses, the MIL administration, the error correction and the fulfillment of further requirements demanded by law are tasks of the functions which are assigned to block e.). The block e.) Communicates with the blocks a.) To d.) And f.) To h.), As indicated by the arrows or double arrows. Input variables from block e.) Are requests, for example for releases for operating mode switching, from block h.), I.e. the controller. Input variables from block e.) Are still requirements, for example for releases for model adaptation, from block d.), I.e. the observer. Input variables from block e.) Are also diagnostic statuses and results from block g.), I.e. the diagnostic function. Input variables from block e.) Are also diagnostic statuses and results from block c.), That is, the communication interface. Input variables are also diagnostic statuses and results from block a.), I.e. the sensor interface. Input variables are ultimately also the diagnosis status and results from block b.), I.e. the actuator interface. Output variables from block e.) Are releases to block h.), D.) And f.) As well as releases and locks to block g.) And error memory information to block c.).

In the structure, block f.) Represents the reconfigurator to which functions are assigned which have the task of reconfiguring block d.) And / or block h.) In the event of an error. Under the term "reconfiguration" is a signal, structure or parameter switchover during runtime. The reconfiguration is based on the diagnostic results. If, for example, a sensor is recognized as defective in a diagnostic function, then the functions assigned to block f.) Should trigger the necessary signal and structure switchovers in block d.). If an actuator or another system component is recognized as defective, then both block d.) And block h.) Should be reconfigured accordingly. The block f.) Is connected to the block e.), The block d.) And the block h.) For the exchange of data / information, as indicated by the arrows or the double arrow. The input variables of block f.) Are the diagnostic information managed by block e.). Output variables of block f.) Are requests for reconfiguration that go to block h.) And / or block d.). The use of a reconfigurator leads to an increase in the error tolerance of the overall system or the device for controlling and regulating a drive system, since in the event of an error during runtime, triggered by the reconfigurator, it is possible to switch from a measured value to a model value.

In the structure, block g.) Represents a diagnostic function, which in turn is assigned functions which have the task of being able to carry out a diagnosis. In block g.) There are signal- and / or model-based diagnostic functions. The necessary information about system states and residuals, which serve as the basis for these diagnostic functions, is provided by block d.). The diagnostic functions also have the option of influencing the control signals or setpoints in block h.) In order to be able to carry out an active diagnosis. The block g.) Communicates with the block d.), The block e.) And the block h.), As indicated by the arrows or the double arrow. The input variables of block g.) Are the measured and modeled signals including the residuals from block d.) And the diagnostic release information of block e.). Output variables of block g.) Are diagnostic results and status information that are transmitted to block e.) And manipulation of setpoint values for carrying out active diagnoses, which are transmitted to block h.).

In the structure, the block h.) Represents a controller, to which functions are assigned that have the task of generating setpoints and control signals, making strategic decisions and coordinating the components, i.e. coordinating the functions and modules that make up a certain hardware components, such as the fresh air or exhaust system of a vehicle. The information received from block d.) Is primarily used as the basis for these tasks. The following categories of functions can be contained in block h.), Such as regulator functions, controls, setpoint generation, strategic decision, such as switching operating modes or coordinating drive train components. The functions contained in block h.), Like those of block d.), Can be assigned to the individual hardware components. The block h.) Is connected for the exchange of data / information with the blocks b.), C.), D.), E.), F.), G.) And h.), As indicated by the arrows Double arrow and the bold arrow indicated. Input variables are reconfiguration information from block f.), Release information from block e.), Setpoint manipulations from block g.), External information such as torque setpoints from the gearbox that arrive via block c.) And the measured and / or modeled signals from the block d.). Output variables are the control signals that go to block b.) And block c.), Adaptation values and information about control stops to block g.) And release requests to block e.).

In summary, the modular structure is kept so general that it can also be used for more complex drive systems. For example, with regard to the operation of motor vehicles, active brakes or hybrid drive concepts with their specific actuators and system components can easily be implemented. No changes to the structure are required for this, the development effort is limited solely to the functions assigned to the individual blocks, for example relating to drive management in block h.). The level of detail in this description takes into account the requirement for general validity. No descriptions of functions, implementation aspects, computation grids, or operating states are disclosed. Rather, the purpose and the principle interaction of the structure blocks a.) To h.) Defined in the following section are to be described. These structure blocks a.) To h.) Are the containers for the functions and modules to be developed. Which of these components, which are preferably implemented as software, fill this container in the special case of a certain drive, depends solely on the technical requirements. For example, only in the event that a secondary air pump is present in the system as part of an application in the area of internal combustion engines, a corresponding diagnostic function should also be integrated into the control unit code.

In the 1 Blocks a.) to h.) shown, which describe the system architecture, now contain a large number of modules and functions. These in turn generally work with different time grids. Basically are the following calculation grid is to be provided. Crank angle-synchronous grid, such as an ignition-segment-synchronous grid of an internal combustion engine and, in relation to a high-pressure injection pump of an internal combustion engine, a delivery stroke-synchronous grid. In addition, it is expedient to provide time-synchronous rasters, for example 1 ms, 10 ms, 20 ms, 100 ms and so on. Event-driven tasks are also conceivable, such as executing the reconfiguration only in the event of a corresponding error. Care should be taken to ensure that the signals read in from block a.) Are appropriately sampled so that no aliasing occurs. It should also be noted that anti-aliasing filters must be provided when signals are re-sampled with a longer sampling time if there is a significant energy content above the Nyquist frequency.

According to 1 the structure also includes the block i.), which contains classes of functions in a library that are called at runtime. It can be, for. B. to be an optimizer, a recursive estimation algorithm or the like.

According to 1 the structure also includes the block j.), which contains the core functionalities of the underlying control device, which include the operating system and the task scheduling, among other things.

According to 1 the structure also includes block k.), which represents the interface to an application system, i.e. the hardware, communication and software required for this. This block is intended to ensure that the parameters of the functions can be adjusted using a PC via a standard interface and signals such as measured values and calculated signals can be recorded from the control unit.

Finally, the structure also includes block I.), which is used to monitor the control device, which is not described further, with regard to impermissible acceleration of an underlying vehicle.

1. 1. Luftsystem (Air System)
2. 2. Kraftstoffsystem (Fuel System)
3. 3. Verbrennungsprozess (Combustion)
4. 4. Abgassystem (Exhaust System)
5. 5. Antriebsstrang (Powertrain)
6. 6. Kühlsystem (Thermal System)
7. 7. Elektrisches System (Electrical System)

The architecture provides for the grouping of functions of block h.) And block d.), And as far as possible also of the other blocks, into physically oriented modules. A generally applicable subdivision into modules for the most varied of internal combustion engines is the following:

1. 1. Air system
2. 2. Fuel system
3. 3. Combustion process
4. 4. Exhaust system
5. 5th powertrain
6. 6. Cooling system (thermal system)
7. 7. Electrical system

In the course of expanding the respective control unit software for further drive concepts, the above list can be extended accordingly.

The architecture allows different operating states in addition to normal operation, e.g. B. the initialization and the follow-up. In the "Initialization" operating state, all control unit functions are initialized. In the "Run-on" operating state, any stationary adaptations are carried out, adaptation values are written to the non-volatile memory and so on. The more detailed definition of these and possible other operating states depends on the functions to be developed. Since the architecture essentially defines signal flows, this does not constitute a contradiction to any other operating states.

The following aspects are expressly not part of the architecture described here. With regard to the ECU hardware, the software architecture is independent and should be able to be implemented on a wide variety of target platforms. With regard to the engine and drivetrain hardware, the software architecture should cover a broad spectrum, particularly of vehicle concepts. In connection with the implementation of the functions, the function development cannot and should not be anticipated. The architecture description has a general character and should not depend on the implementation of the necessary functions, but rather allow all technically meaningful implementations.

According to 2 The modular structure can also be represented as part of a device for controlling and regulating a drive system from the perspective of the network for the creation of open standards for software architectures of motor vehicles, AUTOSAR. The AUTOSAR standard provides for the ECU software to be subdivided into the application layer and the infrastructure layer. These two layers exchange data via the so-called run time environment (RTE). The latter forms an interface that enables the application software to be decoupled from the hardware. The RTE is also used for communication within the application layer. There are both architecture blocks whose content is exclusively above the RTE (e.g. the controller and the observer) and blocks which contain parts above and below the RTE (e.g. the actuator interface, the sensor Interface, the diagnosis manager, the library).

According to 3 block a.), i.e. the sensor interface, is shown in detail. The sensor interface forms the hardware-specific interface of the device according to the invention for controlling and regulating a drive system or a control device with regard to the sensors. The sensor interface contains functions for the basic processing of the raw sensor signals sent to the control unit by the sensors. The sensor interface has a modular structure to enable the software to be easily adapted to changes in the sensor hardware. The input signals of the sensor interface are the output signals of the sensors. The interface is structured by two layers. The hardware access layer is at the lowest level. This contains the hardware-specific drivers for reading out the input interfaces (hardware driver). These are, for example, drivers for access to digital and analog converters (ADC) of the ECU hardware used. In addition, diagnostic results relating to the hardware status (Diagnostic Service) are supplied by the layer (Inp modules or input modules), these usually being status words or binary variables. The sensor signal conversion layer is located above the hardware access layer. It comprises sensor functions that convert the raw sensor data supplied by the hardware access level into physical sensor values (transformation) and carry out simple electrical diagnosis (low-level diagnosis, range check, plausibility). According to AUTOSAR, the lowest level of the sensor interface is part of the basic software of the ECU. From a conceptual point of view, the hardware access layer is separated from the sensor conversion layer by the runtime environment (RTE). The physical sensor values (summarized in the SensorBus) are forwarded to the observer in block d.). In addition, the results of the diagnoses carried out in the sensor interface are summarized in the SensorStatusBus and passed on to block e.), I.e. the diagnosis manager. These external interfaces can be implemented via signal buses in the course of an implementation, for example in SIMULINK ^®.

Hardware components for signal acquisition (A / D converter, digital I / Os) are controlled in the hardware access layer. The voltage values supplied by the hardware driver are processed further by the conversion functions contained in the sensor conversion layer. The electrical signals are converted into physical quantities such as pressure or temperature. The sensor values are passed on from the sensor interface to the observer, i.e. to block d.), In the smallest time frame required by the function. An additional task of the sensor conversion layer is to carry out hardware-related basic diagnoses and, if necessary, to carry out a signal plausibility check. The diagnosis includes simple electrical diagnoses (signal range check of the incoming sensor voltages). Plausibility checks are only carried out in the sensor interface if redundant sensor information is available for a measured value, e.g. B. for the throttle valve opening angle by two position sensors. Since these functions are close to the hardware, they should serve as a hardware abstraction layer. If a sensor S from ABC company is exchanged for another sensor S from XYZ, then only the sensor interface function S should be affected. Therefore, there should be no cross-coupling between conversion routines that are located on one level of the sensor interface.

According to 4th a basic representation of the signal flow from the converted sensor voltage value, which is supplied by the ADC, to the actual value, which is then used by the functional software or is supplied to block b.) and / or block h.). After the sensor signal has been processed by the sensor interface, the physical actual sensor value is passed on to the observer in block d.). The value can be corrected in the observer using a suitable adaptation strategy. The sensor value is then passed on to a selection block, which can be used to switch between the replacement value (Backup Value), a modeled (Model Value), the measured (Correction) and an additionally filtered sensor value (Filter). The results of the hardware diagnosis and low-level diagnosis of the sensor interface are passed on to the diagnosis manager or block e.). The diagnosis manager also receives the results of the diagnoses calculated from the observer residuals (model value minus actual value) in block g.). With the help of a decision strategy, a switch to a substitute or model value in the observer is then carried out via the reconfigurator in block f.). A feature of the sensor interface is that a conversion routine for calculating the physical sensor measurement value is available for each converted raw sensor value. Another feature of the sensor interface is that an electrical diagnosis can be carried out for each analog sensor value. Yet another feature of the sensor interface is that the sensor values can be passed on in the smallest time frame required on the functional side, with the increase in the time resolution requiring a functional requirement. Another feature of the sensor interface is that signal filtering is then carried out in the sensor Interface can be carried out if only a filtered value is required from all functions that use this value in the smallest time grid. In other words, the filtering is only carried out in the sensor interface if the sensor value is not required by any function in the system as an unfiltered signal in the smallest time frame. Another feature of the sensor interface is that if two sensors of the same type are available for the acquisition of a physical signal, such as two position sensors of the accelerator pedal of a motor vehicle, then the corresponding conversion routine should, if possible, check the plausibility of the redundant signals and mutually provide a single physical value. Yet another feature of the sensor interface is that no cross couplings are permitted between the conversion routines of the sensor interface, that is to say, for example, the use of the speed signal for the conversion routine of the boost pressure sensor. This is intended to support the simple interchangeability of sensors.

The interfaces within block a.) Are characterized as follows. When the layers are communicating, the signals are grouped and, for example, sent via buses between the blocks, i.e. communication between the layers of the sensor interface takes place, for example, when implemented in SIMULINK ^® via buses, which enable clear signal grouping. This does not affect the option of using other implementation tools ^{such as ASCET ®.} In this case, the signals can be grouped by using appropriate identifiers for the signals, which, if necessary, have to be declared as messages. The input signals made available by the hardware driver are grouped in buses and passed on to the conversion layer. Analog sensor signals are grouped in a bus. Digital sensor signals, such as bit sizes, pulse duty factors, frequencies, and periods are also grouped in a bus. In addition, angle-related sensor input signals from the crankshaft and camshaft are grouped in a bus. The diagnostic results of the hardware access layer are summarized in a bus and passed on to higher layers.

The functions to be implemented within block a.) Can be characterized as follows. The sensor interface includes conversion routines for the following sensor signal types: for analog sensor signals, such as from a temperature or pressure sensor, for special analog sensor signals, such as from a knock sensor or a lambda probe, for switches, such as a door contact switch, for speed -Sensor signals, for example from an inductive or Hall sensor, for pulse-width-modulated digital sensor signals, such as from an HFM sensor, for special digital sensor signals, such as from an oil level and temperature sensor. In the case of conversion routines for analog sensor signals and also special analog sensor signals and periodic, digital sensor signals, a low-level diagnosis with checking of the range limits of the sensor signal is carried out. In the case of measured variables that are recorded by two sensors of the same type, for example throttle position sensors or accelerator pedal position sensors, a mutual plausibility check of the signals is carried out and one of the signals in the SensorBus is forwarded to the observer in block d.). Hardware-specific routines and drivers for accessing hardware input modules and reading hardware-related status information are located in the hardware access layer. The functions are highly hardware-dependent. They enable access to analog and digital input modules and special input modules, such as for evaluating knock and lambda sensor signals. The evaluation of a temperature sensor in the sensor interface is intended to illustrate the processing of a sensor signal by way of example. The analog voltage signal from the sensor is passed on from the hardware access layer to the conversion routine. In addition, status information about the state of the A / D converter and the hardware is passed on. A temperature value is then calculated, for example, using a characteristic curve from the voltage value read out. In the conversion routine, the signal range is also checked and the diagnostic result is returned. The status information is passed on in the SensorStatusBus and the measured temperature value in the SensorBus.

According to 5 block b.), i.e. the actuator interface, is shown in detail. On the one hand, the actuator interface contains functions that are responsible for processing control signals and make these available as input signals to the output stage drivers. On the other hand, the actuator interface also includes hardware-specific functions that generate additional driver signals required to control output stages, such as the charging time of ignition coils of an internal combustion engine. The actuator interface basically consists of two hardware-specific levels. In one level, the control signals coming from block h.), I.e. the controller, via the ControlBus are converted into input signals for the hardware-related drivers; this is, so to speak, the signal processing level. Analogous to block d.) And block h.), This level is divided into the following hierarchies: Air System, Fuel System, Powertrain, Thermal System, Exhaust System and Combustion System. The second The actuator interface level is the driver level as the interface to the peripherally connected output stages. According to AUTOSAR, it is part of the basic software of the ECU. From a conceptual point of view, the two levels are separated by the Runtime Environment (RTE). Buses are defined as the interface between the actuator interface and other blocks of the AUTOSAR application layer. The input variables of the actuator interface are the ControlBus and the SystemBus. The ActuatorStatusBus is brought out of the actuator interface. The ControlBus, which is generated in block h.), Contains all physical and logical control signals from all regulators and controls. This also includes bits for activating the output stages. The SystemBus, which is put together in block d.), Is made up of the measured and / or modeled signals or actual values. The ActuatorStatusBus contains the status signals of all output stages, which are made available as output signals from the output stage diagnosis functions, as well as the status bits that are generated as part of a value range check after signal processing. The status signals of the output stages include signals that, for example, reproduce information about short circuits to ground or positive of the individual outputs of the output stage. The status signals combined in the actuator interface to the ActuatorStatusBus are made available to the diagnosis manager in block e.) For further processing. If necessary, before assembling the ActuatorStatusBus, the individual diagnostic signals, which are dependent on the system manufacturer, can first be converted into a format specified by the diagnostic manager in block e.) In the actuator interface or the system manufacturer does not provide an interface for the Diagnosis of the power output stages is provided, a previously defined substitute signal is generated at this point and further used. For the implementation of the data buses mentioned here, for example, ^{so-called bus objects are available in SIMULINK ®} in order to meet the requirement for data consistency in a suitable manner.

The signal processing converts the physical control signals, if necessary with the aid of additional information, into input signals for the output stage driver. Depending on the connected actuators, there is a software component for signal conversion for each actuator. When an actuator A from company ABC is exchanged for another from company XYZ, the software components for signal processing and the associated driver for the actuator to be replaced are also affected by the exchange and must be adapted accordingly. As a result, cross-couplings between the individual functions within the signal processing or driver level are not permitted, so that the interfaces of other software functions do not have to be adapted when actuators are replaced / omitted. If, on the other hand, an actuator xyz is omitted, the associated software component for converting the physical control signal and the output stage driver for this actuator xyz are also omitted. In this case, the associated software functions in block h.) And, if necessary, in block d.) Must be adapted. It behaves accordingly when an actuator is added. To control the additional / new actuator, a corresponding software component for signal processing and a driver component for controlling the associated output stage must be added to the actuator interface. The block h.), I.e. the controller, must be adapted so that a corresponding manipulated variable is also generated for this added actuator.

The interfaces within block b.) Are characterized as follows. If only individual driver signals are transferred from the respective software functions from the signal processing level to the associated drivers, only signals are used as interfaces. Before calling up a software component to process a physical signal, the control signal to be converted from the ControlBus and the signals from the SystemBus that are required for conversion and, if necessary, further signal processing (scaling) must be selected. The output signal available as a result of the signal processing is made available directly to the corresponding output stage driver from the driver level for further processing. If, on the other hand, several signals have to be transferred to an output stage driver, these signals have to be combined as a bus within the signal processing level and transferred to the output stage driver as a bus. This also ensures consistent data transfer, even if the signal processing and the output stage driver are called in different tasks.

The functions to be implemented within block b.) Can be characterized as follows. This is in the 6th the signal processing exemplarily illustrated for the actuator xyz. Immediately before the associated software component for signal processing is called up, the desired control signal and, if available, an enable bit to activate the associated output stage is selected from the ControlBus. If further information, such as the speed or the battery voltage, is required for processing, this must be made available by the SystemBus. The selected signals are then transferred to the respective software component. If the control has been enabled via the controller (enable bit set to TRUE), takes place under Consideration of the physical dimension the signal processing through a generally non-linear mathematical link of the selected signals. The processed signal is then checked for its value range, the minimum (y _min ) and the maximum permissible value (y _max ) depending on the actuators to be controlled and both values being adjustable. If the permissible value is undershot or exceeded, a status bit is set and the processed signal is limited _{accordingly to y min} or y _max. If, on the other hand, the control of the actuator has not been enabled, depending on the driver, signal processing is either not necessary or the signal to be processed must be set to a special value (e.g. charging time of the ignition coils = 0s if it is not to be ignited). The driver input signals and the enable bit set to FALSE are transferred directly to the output stage driver as a bus. If necessary, the enable bit can also be converted into a format specified by the system manufacturer in each software component for signal processing, or if the system manufacturer does not provide an interface for activating individual power output stages, the enable bit is used for these output stages not forwarded to the driver level. The signal processing will now be demonstrated using an example. The rail pressure regulator as part of block h.), I.e. the controller, calculates a fuel quantity to be delivered in, for example, liters per hour, depending on the prevailing operating conditions. In the actuator interface, this is first converted into an angular range and, using the engine speed, into a period of time, with additional information, some of which is hardware-specific, such as the number and contour of the cams, the inductance of coils, the battery voltage. The start of the control in the form of an angle and the duration of the control are the input variables of the output stage driver coming from the actuator interface, which determine the timing for the control of the quantity control valve. If the angle and duration exceed or fall below their respective minimum and maximum permissible values, the corresponding status bits are set and the values are limited accordingly. The signal for controlling the output stage is finally generated by the output stage driver as part of the complex driver from the driver level. If, for example, the valve characteristic of the quantity control valve changes in the course of use and this can be quantitatively described with the aid of further variables from the SystemBus, corrective intervention is possible with the present architecture within the scope of the signal processing of the actuator interface. The dashed lines for the selected signals from the ControlBus and SystemBus are intended to indicate that the generation of the input signals for the individual output stage drivers can in part also be generated from signals from the SystemBus without information from the SystemBus or individual driver inputs, for example the charging time of the ignition coils.

Block d.), I.e. the observer / signal processing, is described in detail at this point. The functions of this block have the task of observing the current actual state of the system to be controlled and regulated, in particular an internal combustion engine in a motor vehicle. This observation takes place with the help of a model. Simplified non-linear dynamic models are used to estimate the measurable and non-measurable state variables of the system based on the control signals and the environmental conditions. Modeled measurable states are compared with measurement signals and residuals are generated from them. On the basis of these residuals, an observer feedback is implemented in order to correct the modeled state variables. The principle of a state observer is in the 7th shown. As a status observer, the observer / signal processing according to block d.) Implements the following functions. On the one hand, there is the observation of the system states, whereby these observed states can be used on the one hand to use non-measurable variables for control and regulation. On the other hand, in the event of an error, the observed states can be used as substitute values for the measurement signals. The observer functions should supply the functions of block h.), I.e. the controller, and block g.), I.e. the diagnostic function, with information about the current system status and with residuals. As far as possible, block d.), I.e. the observer, should ensure that the functions of block h.) Can be implemented independently of the sensor configuration. In addition, the observer / the signal processing according to block d.) Should implement model- or signal-based sensor adaptation methods which reduce the influence of the measurement accuracy of the sensors.

The block d.) Therefore not only represents a status observer, but also contains further functions for signal processing. Particularly noteworthy at this point is the sensor adaptation, which is used to reduce the influence of the sensor inaccuracies. In order to be able to carry out a sensor adaptation or correction, information from other sensors and models is required. Since this information is available in block d.), The sensor correction and adaptation also takes place there.

According to 8th the functions of the observer for the overall system are grouped into the following three levels. "Model Layer" ( Model level), "Observer Feedback" layer and "Sensor Adaptation and Correction Layer". The three levels presented above are described in more detail below.

With regard to the functional principle of an observer, the interaction of forward-looking process models, which are arranged in the “Model Layer” level, and the observer feedback, which is located in the “Observer Feedback Layer” level, is of essential importance. The feedback ensures that the process states calculated by the models, such as pressures, speeds, temperatures, dynamically match the actual values. The feedback can be freely parameterized; in particular, it can also be structured in such a way that repercussions, i. H. Corrections remain limited to certain subsystems. In this way, the problem of designing a “large” observer using all the information can be reduced to the much easier-to-solve problem of designing smaller observers for individual sub-models. In other words, the feedback can be designed in such a way that, for example, the drive train of a motor vehicle is used to correct the air path of the internal combustion engine used, since both are coupled via the speed, and vice versa. Alternatively, the feedback can also be parameterized in such a way that the air path is corrected only on the basis of the information from the air path and the drive train is corrected only on the basis of the information from the drive train, i. H. the information remains locally restricted to the modules. In many cases it is possible to reconstruct the state variables from different measured variables, i. H. the system remains observable for different sensor configurations. If, for example, a sensor fails during operation and this is detected, the state variables can still be observed using an alternative observer feedback. In this way, a previously measured variable can be replaced by a reconstructed variable. This process is implemented in the “Observer Feedback Layer” using the “Compare and Select” (CnS) functions. The block d.) Also performs functions that go beyond the observation of the system state. The “Sensor Adaptation and Correction Layer” contains functions for correcting and adapting the sensors, as described later.

The communication between the levels within block d.) Is in 9 shown. The input variables / signals of the model level are the SensorCBus, the ControlBus and the OfbBus or the signals contained in these buses. The SensorCBus contains the corrected and adapted sensor signals from the sensor correction level. The ControlBus contains the control signals generated by block h.). The OfbBus contains the correction from the observer feedback level. The output variable of the model level is the ModelBus, which contains all modeled (estimated) signals. The input variables / signals of the sensor correction level are the SensorBus, the ResidueBus, the OfbBus and the ModelBus or the signals contained in these buses. The SensorBus contains the sensor data / signals from the sensor interface, i.e. block a.). The ResidueBus contains the calculated residual signals from the return level (CnS functions). The OfbBus contains the correction from the observer feedback level. The ModelBus contains all modeled (estimated) signals from the model level. The sensor correction level evaluates the signals contained in the buses mentioned, so that the output variables of the sensor correction level are the corrected sensor signals contained in the SensorCBus. The input variables of the feedback level are the ModelBus, the SensorCBus and the ReconfigBus or the signals contained in these buses. The ModelBus contains all modeled (estimated) signals from the model level. The SensorCBus contains the corrected and adapted sensor signals from the sensor correction level. The ReconfigBus contains reconfiguration information from the reconfigurator, i.e. block f.). The observer feedback level evaluates the signals contained in the buses mentioned, so that the output variable of the observer feedback level is the OfbBus, the ResidueBus and the SystemBus, or the signals contained therein. The SystemBus contains the sensor variables and model variables selected in the “Compare and Select” (CnS) functions, which describe the current state of the engine / vehicle.

In 9 the signals sent by the controller, ie block h.), via the communication interface, ie block c.), are not shown. These are treated in exactly the same way as the controller bus, since they are nothing more than control signals that are not output via the actuator interface in block b.).

The following functions are to be implemented within block d.). The model level contains process models of the engine and drive train. These process models are grouped into modules that are used as follows for a model description of an internal combustion engine in connection with 8th being represented. The “Air System Model” (AirSysMdl) module contains a model of the intake-side air system of an internal combustion engine. This also includes the gas exchange model known as charge detection. Variables such as pressures, temperatures, filling (fresh air and possibly residual gas) are modeled. Depending on the vehicle, this model must be adapted, i.e. configured. Variants here are, for example, a naturally aspirated or charged internal combustion engine with or without external exhaust gas recirculation.

The Fuel System Model (FuSysMdl) module contains a model of the fuel system of an internal combustion engine, consisting of the low and high pressure sides. It includes, among other things. the components tank, fuel pump, activated charcoal canister (tank ventilation), high pressure pump, rail and injection valves. Quantities such as pressures, temperatures and fuel mass flow from the tank ventilation are modeled. Depending on the vehicle, the model must be adapted system-specifically. Variants here are, for example, an internal combustion engine with intake manifold or direct injection or the type of high-pressure fuel pump used.

The “Combustion Model” (CmbMdl) module contains a thermodynamic model that balances the energy in the combustion chamber. The mechanical energy or torque, the heat flow through the cylinder walls or the coupling to the cooling system, the energy flow in the exhaust system (possibly the individual species), the combustion chamber lambda, and the combustion focus are to be modeled. The selection of the variables to be modeled also depends on the operating method of the underlying internal combustion engine, that is to say whether it is, for example, an Otto, Diesel or Otto self-ignition method.

The module "Exhaust System Model" (ExSysMdl) contains a model of the exhaust system of an internal combustion engine from the exhaust valve to the exhaust. It describes the dynamics of pressure and temperature as well as the exhaust gas lambda. The model is configured depending on whether it is an internal combustion engine with or without an exhaust gas turbocharger or depending on the number and type of catalytic converters.

The “Powertrain Model” (PtMdl) module contains a drive train model that provides parameters such as engine speed, longitudinal vehicle speed, longitudinal acceleration, torsion angle, transferable clutch torque, driving resistance or gradient angle. Depending on the vehicle, this model must be adapted. Variants are, for example, whether it is a drive concept with a manually operated change gearbox, an automatic gearbox or a parallel hybrid, i.e. a combination of an internal combustion engine and an electric machine.

The module "Thermal System Model" (ThSysMdl) contains a model of the cooling system. It describes the temperatures of the various cooling circuits and must also be configured depending on the drive concept.

The module "Electrical System Model" (EISysMdl) contains a model of the electrical system of a drive concept. For example, it can be a simple battery model or, in the case of a hybrid drive, a complex model of the power electronics and the electric drives.

In the observer feedback level / feedback level, there is a module for each hardware component in which two functions are accommodated. These implement the calculation of the observer feedback (Ofb functions) and the calculation of the residuals including the selection of the signals written in the SystemBus (CnS functions). The observer feedback determines a correction value from the residuals. The entire residual bus is used; H. In principle, all residuals of all models can be used to calculate the correction value.

The correction value calculated for a component model is calculated according to the in connection with 9 The described communication method is fed into the relevant model and is used there to correct the estimated state. A signal selection is made in the CnS functions. This signal selection is an example in 10 shown, with a choice being made between a modeled value / sensor signal CR_pMdl, a measured value CR_pMesC, measured and filtered value CR_pFlt and a substitute value CR_pSub_C. The selection is made via a status variable read from the reconfiguration bus, here CR_stRec. In addition, the residual CR_pResi belonging to the respective measurement signal CR_pMesC is calculated as a deviation between the measurement value CR_pMesC and the model value CR_pMdl.

In the sensor correction and adaptation layer, functions are implemented which, for example, carry out a sensor correction on the basis of a stationary, non-zero residual. An example of this could be the adaptation of a pressure sensor, a pressure offset being determined by an adaptation algorithm, which is then stored in the non-volatile memory. The calculation of the sensor value with this adaptation value is then referred to as sensor correction.

According to 11 the scope of block e.), i.e. the diagnosis manager, is shown. The diagnosis manager is a central administrative organ of the device for the control and regulation or the respective control device on which the respective drive concept is based. The block e.) Contains all modules and in their care all functions that are required for the central organization and coordination of the system processes or for the central recording and mapping of the system status. Its tasks consist of the central recording, administration and control of internal processes in the control unit as well as the provision of information for the communication interface. The block e.) Consists of the modules “Diagnostic Manager” (including fault memory), “Coordination Manager”, “Symptom Manager”, “Statistic Tools”, “Production / End of Line / Garage” and “System Manager”.

In the diagnosis manager, all information about the operating sequence and the system status is collected, analyzed and mapped centrally. The evaluation of this information takes place centrally and is used to plan further system processes. In this context, the “Coordination Manager” module is of central importance as the coordinator of the internal system processes. The “Symptom Manager”, “Diagnostic Manager” and “Statistic Tools” modules play an important role in fulfilling the legal requirements and, in particular, the requirements in the area of on-board diagnostics (OBD). A separate placeholder ("Production / End of Line / Garage") is provided for handling requirements from the areas of production, end of line and workshop. The “System Manager” module serves as a container for all other, also cross-system, functionalities that are related to or need to be related to the engine control unit.

The internal communication and the essential signal flow within the diagnostic manager are in 12th shown. As a central element relating to all processes in the Diagnostic Manager, the “Coordination Manager” module is of decisive importance for the system processes. The planning of the system processes depends on the results of the diagnoses ("Diagnostic Manager") and the requirements from the "Statistic Tools", "System Manager" and "Production / End of Line / Garage" blocks. The SysCoordBus and the xxxStatusBus are used as communication interfaces to the other blocks of the architecture, whereby "xxx" stands for synonyms of the block names, thus representing, for example, "diagnostic function". The generation of a clear diagnosis result (pinpointing) is the task of the "Symptom Manager" module, which evaluates (including pre-debouncing) the information from block a.), I.e. the sensor interface (SensorStatusBus), and block b.), I.e. the actuator Interface (ActuatorStatusBus, so for "xxx" stands for "Actuator"), and the block g.), Ie the diagnostic function (DiagnosisBus), takes over.

It communicates its result to the “Diagnostic Manager” module and via the DiagResultBus. The “Diagnostic Manager” module implements the error memory entries, their management and transmission to block c.), I.e. the communication interface via the (ComlnBus / ComOutBus). The “Statistic Tools” module accesses the results of the “Diagnostic Manager” and other system information from various buses. In the context of z. B. the IUMPR he also accesses the "Coordination Manager", where "IUMPR" stands for "In use monitor performance ratio" and refers to the frequency of selected discontinuous diagnoses, with a precise definition of "Title 13, California Code Regulations, Section 1968.2 "as the governing guideline for certification in California. External communication takes place via the ComlnBus and ComOutBus buses. In the “System Manager” and “Production / End of Line / Garage” modules, functionalities can be called up and executed via the “Coordination Manager” module (e.g. short trips, actuator tests). Communication via the communication interface, i.e. block c.), Via the ComlnBus / ComOutBus buses enables data to be exchanged with the periphery. The system information required is taken from the SystemBus. To support maintenance, information from the DiagnosisBus, the “Symptom Manager” and the “Diagnostic Manager” can be used in the “Production / End of Line / Garage” module. Internally, the requirements are forwarded to the "Coordination Manager" for coordination.

The "Diagnostic Manager" module contains the acquisition and management of the diagnostic results. This also includes the implementation of functionalities such as debouncing and healing as part of the on-board diagnosis. In addition, mechanisms for dealing with FreezeFrames and the control of, for example, MIL (Malfunction Indicator Lamp, display of errors in the context of OBD), EPCL (Electronic Power Control Lamp, EGAS monitoring) are provided.

The "Coordination Manager" includes the locking and prioritization of functions on the basis of diagnostic results and system requirements. The module outputs are function calls. This is essentially done by prioritizing the requirements and thus the functional processes, a corresponding release or blocking of functions depending on the system status and diagnostic results (via SysCoordBus) and the monitoring of the functional processes (via xxxStatusBus).

The "Symptom Manager" is responsible for processing the diagnostic results from blocks a.), B.) And g.), I.e. the sensor interface, the Actuator interface and the diagnostic function. A corresponding cross-locking matrix must be generated to ensure pinpointing. To avoid false alarms (erroneous display of an error), pre-debouncing (e.g. time or event-oriented) must be provided within the "Symptom Manager" module.

The “Statistics Tools” module includes, among other things. Functions for calculating the IUMPR as part of the OBD. Optionally, further statistical evaluation functions and customer-specific system analysis functions can also be stored here.

As part of the “Production / End of Line / Garage” module, functionalities from the areas of production, end of line and workshop are provided. Examples include the initiation of short trips and actuator tests as well as the implementation of adaptation channels and the implementation of the control unit coding.

In the “System Manager” module, functions such as B. WIV (maintenance interval extension) and WFS (immobilizer) stored.

Block h.), I.e. the controller, is also shown in detail. The block h.), I.e. the controller, generates from the block d.), I.e. the observer / signal processing, from block f.), I.e. the reconfigurator, from block e.), I.e. the diagnosis manager, from the block c.), ie the communication interface and from the block g.), ie the diagnostic function, signals provided controls the actuators, ie the controller contains all functions for controlling and regulating the engine and drive train. The control / regulation function belonging to a specific hardware component can thus be identified as a corresponding module. The block h.) Comprises the modules "PtCtl" (Powertrain Control; drive train coordination), "ExCtl" (Exhaust System Control; exhaust system control / regulation), "EffCoord" (Efficiency Coordination), "TqCtl" (Torque Control; moments Control / regulation), "AirCtl" (Air System Control; control / regulation air system), "CmbCtl" (Combustion Control; control / regulation combustion), "FuCtl" (Fuel System Control; control / regulation fuel system), "ThCtl" (Thermal System Control; control / regulation of the cooling system) and "ActCtl" (Actuator Control; control / regulation of actuators). The basic signal flow within the block h.) Is in 13th shown. From left to right, four cascades can be made out, starting with the more process-remote interpretation of the driver's request in the "PtCtl" module, through the torque control / regulation in the "TqCtl" module, the process controllers of the "AirSysCtl" module, through to the throttle position control loop in the "ActCtl" module. Overall, the interaction of the modules can be described as follows. In the "PtCtl" module, the drive train management, a target torque is calculated from the accelerator pedal position and other variables. The "ExSysCtl" module generates efficiency requirements for heating and cooling components of the exhaust gas line. The desired torque serves as a setpoint for the functions of the "TqCtl" module, which is of central importance. It is used to encapsulate the internal combustion engine as a torque actuator and contains an inverse torque model that maps the torque setpoint and the coordinated efficiency requirements from "ExSysCtl" into corresponding setpoints for process variables such as filling and rail pressure, as well as other engine setpoints. The “AirSysCtl” module converts filling and / or pressure target values into a corresponding waste gate control and a target throttle valve angle. The module "CmbCtl" contains, among other things, the ignition angle calculation and the mixture control and regulation. The “FuSysCtl” module controls and regulates primarily the fuel pressures. The “ThSysCtl” module controls and regulates the coolant temperature. The “ActCtl” module contains functions for controlling subordinate actuators, such as B. the throttle valve. All manipulated variables, including any binary variables for enabling / disabling output stages, are combined in a signal bus, the ControlBus. Control signals that are to be sent via the CAN are an exception here, e.g. B. to an electric machine. These are combined in a separate signal bus, the ComControlBus.

According to the representation of the basic signal flow within the block h.) According to 13th the main signal path runs horizontally from left to right. Each module within block h.) Or each function can access the information from block d.), F.), G.) And block e.) In the structure. The drive management contained in the "PtCtl" module within block h.) Also receives external setpoint requests (e.g. setpoint torque from ASR) via the communication interface, i.e. from block c.). Since an internal combustion engine represents a coupled process, the individual controller functions are not completely independent of one another. As indicated by the dashed arrow drawn from the “CmbCtl” module to the “FuSysCtl” module, a vertical signal flow is also possible and necessary. In this special case, the target fuel volume flow generated by the mixture control is applied to the rail pressure regulator function in the sense of a decoupling / interference variable injection. The "PtCtl" module represents the drive management and includes the functions of interpreting the driver's wishes, driver assistance systems (cruise control, speed and speed limiter), torque limitation, Acceleration interface, driveability filter, acceleration control and regulation, torque interface, aggregate coordination (hybrid coordinator and driving strategy), jerk dampers, idle and start-up controller, speed interface. The main output variables are the target torque for the “TqCtl” module as well as control signals (e.g. target torque or target gear) for external units that are transmitted via a bus, e.g. B. the CAN, are sent. Based on an inverse torque model of the internal combustion engine, the "TqCtl" module converts the target torque and the target efficiency from "ExCtl" into corresponding target values, including for filling, high fuel pressure, air ratio efficiency, ignition angle efficiency, efficiency of internal and external exhaust gas recirculation, tumble efficiency. Furthermore, the decision about the combustion process mode (homogeneous, layer, GCI) is part of this module. The "ExSysCtl" module includes functions for controlling and regulating the exhaust system. These include, for example, functions for catalytic converter heating, component protection (catalytic converters and turbine) and smoke limitation. The output variables are target efficiencies / target torques for ignition and lambda as well as the requirement for increasing the idle speed. The “AirSysCtl” module includes functions for controlling and regulating charge and intake manifold pressure and filling. The "FuSysCtl" module includes functions for controlling and regulating low and high fuel pressure, for tank ventilation and for venting the fuel system. The "CmbCtl" module contains functions for ignition and injection valve control, for lambda control and lambda probe heating control as well as for knock control. The “ActCtl” module contains functions for controlling and regulating actuators, e.g. B. the throttle position control loop. The “ThSysCtl” module contains functions for thermal management. This mainly includes the fan control.

Block g.), I.e. the diagnostic function, is also shown in detail. Increasing legal and technical requirements for modern engine management systems make constant testing and monitoring of the entire system, including its sensors, actuators, components and subsystems necessary. The minimum goal is to meet the legal requirements within the framework of the OBD. In addition, the guided troubleshooting and troubleshooting in service and workshop should be supported and the implementation of customer-specific requests made possible. The aim is to detect, localize and identify malfunctions and errors at an early stage in order to avoid consequential damage to the engine and vehicle. The block g.) Contains all system diagnoses that do not fall into the range of the low-level diagnoses in block a.), B) or c.) Or belong to the e-gas monitoring in block l.).

The structuring of block g.) Is based on the structure in blocks d.) And h.), I.e. the observer and the controller. The structure of block g.) Is in 14th shown.

To map the legal requirements, a further module level is introduced in block g.). The background to this is the higher resolution of the components anchored in the legislation with regard to components relevant to exhaust emissions. The additional module level is shown in 15th for the implementation of the relevant directive in California "Title 13, California Code Regulations, Section 1968.2".

Communication within block g.) Runs vertically from top to bottom. The residuals (ResidueBus), model and sensor variables (ModelBus or SensorBus) and releases (via SysCoordBus) are processed as input variables. In addition to the diagnosis results themselves (DiagnosisBus), the outputs of the block include the status of individual diagnoses (DiagnosisStatusBus) and, if an active diagnosis is required, requirements for the controller (DiagnosisControlBus). The structure is in 16 shown.

On the second (sub) module level, the structure is based on the legislation. With reference to the in 15th In the illustrated case, the submodules to be implemented are listed below. A list of the specific functions is not part of this disclosure, since it varies depending on the drive concept and sensor-actuator configuration. The aim of the second module level is to get an assignment between the implemented diagnostic functions and the legal requirements. The submodule "Air System Monitoring" includes functions for the implementation of "Evaporative System Monitoring", "Variable Valve Timing and / or Control System Monitoring", "Positive Crankcase Ventilation System Monitoring" and "Comprehensive Component Monitoring" based on the Title 13 guideline, California Code Regulations, Section 1968.2. The sub-module “Fuel System Monitoring” includes functions for the implementation of “Fuel System Monitoring” and “Comprehensive Component Monitoring” based on the Directive Title 13, California Code Regulations, Section 1968.2. The submodule “Combustion System Monitoring” includes functions for the implementation of “Misfire Monitoring” and “Comprehensive Component Monitoring” based on the Directive Title 13, California Code Regulations, Section 1968.2. The “Exhaust System Monitoring” submodule includes functions for implementing “Catalyst Monitoring”, “Heated Catalyst Monitoring”, “Secondary Air System Monitoring”, “Direct Ozone Reduction System Monitoring”, “Other Emission Control or Source System Monitoring”, “Exhaust Gas Sensor Monitoring ”,“ Cold Start Emission Reduction Strategy Monitoring ”,“ Exhaust Gas Recirculation System Monitoring ”and“ Comprehensive Component Monitoring ”based on the Directive Title 13, California Code Regulations, Section 1968.2. The submodule “Powertrain System Monitoring” includes functions for the implementation of “Air Conditioning System Component Monitoring” and “Comprehensive Component Monitoring” based on the Directive Title 13, California Code Regulations, Section 1968.2. The submodule "Thermal System Monitoring" includes functions for the implementation of "Engine Cooling System Monitoring" and "Comprehensive Component Monitoring" based on the Directive Title 13, California Code Regulations, Section 1968.2.

Furthermore, block f.), I.e. the reconfigurator, is shown in detail. The reconfiguration (reorganization, reorganization) of the system is to be understood as a tool for the implementation of fault-tolerant systems. The reconfiguration uses resources in the system to ensure operation even in the event of an error. The further operation can possibly only take place partially, with reduced performance and / or for a limited time. A high-performance diagnosis that enables precise pinpointing is the basis of a fault-tolerant system and thus for carrying out a reconfiguration. The task of block f.) Is to maintain system operation and system performance in spite of an error occurring in the system, but at least to implement a "limp home" mode (avoidance of getting stuck). The block f.) Is used to adapt and switch the system in the event of an error. In the context of this block, functions and fall-back levels are to be stored which, in the sense of a fault-tolerant system, guarantee safe operation of the motor beyond the point in time when a fault occurs. The basic structure of block f.) Is in 17th outlined. The components / modules are structured analogously to block d.) And block h.). In this way, the reconfiguration strategies belonging to a specific system component can be assigned to a module.

Block f.) Comprises the reconfiguration strategies assigned to the individual modules, which differ in terms of form and scope. It should be noted that block f.) Is only active when an error has occurred in the system, has been diagnosed and a corresponding reconfiguration request has been made to block f.) By the diagnosis manager in block e.).

Depending on the respective reconfiguration strategy, block f.) Can jointly access block d.), H.) Or block d.) And block h.). The principle is in 18th shown schematically for the “Air System” module. As an example of a simple implementation, see 10 and the accompanying text. Depending on the system configuration and the error situation, it is possible to switch to various substitute values for a sensor value. The reconfiguration strategies are highly dependent on the system and the sensor-actuator configuration used. In addition, each reconfiguration measure must be checked as an individual case in the event of an error (security, system stability). For these reasons, the strategies are stored as individual functions (software components) in the respective modules. Communication within the respective module runs horizontally from left to right. The diagnostic results (DiagResultBus) and the releases (via SysCoordBus) are processed as input variables. The outputs of the block are the status of the individual reconfiguration functions (ReconfigStatus-Bus) and the respective reconfiguration measures (ReconfigBus). In other words, each strategy (function) generates output variables from the input variables in accordance with the stored functionality, which distributes the blocks a.) To h.) In the system or the modular structure. It is crucial that each reconfiguration strategy should be viewed in isolation and that there are no cross-links or connections between the strategies.

Claims (6)

A device for controlling and regulating a drive system, which comprises a computer program code, the computer program code being structured in several blocks, the blocks including functions for controlling and regulating the drive system as delimitable components of the computer program code, the device comprising at least one hardware-specific sensor interface, The sensor interface is assigned functions for basic processing of the raw sensor signals sent to the device for controlling and regulating the drive system of sensors, the sensor interface being structured by two layers, with a hardware access layer being located on the lowest level a sensor signal conversion layer is located above the hardware access layer, the hardware access layer and the sensor signal conversion layer being separated from one another by a runtime environment, the hardware access layer for each includes individual sensor functions for controlling hardware modules for the acquisition of electrical signals, the sensor signal conversion layer for each individual sensor including functions for converting the electrical signals into physical quantities, the sensor interface with an observer for correcting / adapting the with the device for the control and regulation of the drive system connected sensors interacts, the observer being assigned functions that Correct / adapt the signals from the sensors as a function of the signals from other sensors and / or models, the sensor interface interacting with the observer with a diagnosis manager, a diagnosis function and a reconfigurator, the results of the hardware diagnosis and the electrical diagnoses of the sensor interface are passed on to the diagnosis manager, the diagnosis manager still receiving results of the diagnosis function, the results of the diagnosis function being calculated from residuals determined by the observer, using a decision strategy via the If necessary, a switchover to a substitute or model value in the observer is carried out in the reconfigurator. A device for controlling and regulating a drive system, which comprises a computer program code, the computer program code being structured in several blocks, the blocks including functions for controlling and regulating the drive system as delimitable components of the computer program code, the device comprising at least one hardware-specific sensor interface, The sensor interface is assigned functions for basic processing of the raw sensor signals sent to the device for controlling and regulating the drive system of sensors, the sensor interface being structured by two layers, with a hardware access layer being located on the lowest level a sensor signal conversion layer is located above the hardware access layer, the hardware access layer and the sensor signal conversion layer being separated from one another by a runtime environment, the hardware access layer for each individual sensor functions for controlling hardware modules for the acquisition of electrical signals, the sensor signal conversion layer for each individual sensor including functions for converting the electrical signals into physical quantities, with no cross-coupling between the individual functions of the hardware access layer and between the individual functions of the sensor signal conversion layer are no cross-coupling, the sensor interface interacts with an observer to correct / adapt the sensors connected to the device for controlling and regulating the drive system, the observer being assigned functions that depend on the signals from other sensors and / or models correct / adapt the signals from the sensors, the sensor interface interacting with the observer, a diagnosis manager, a diagnosis function and a reconfigurator, the results the hardware diagnosis and the electrical diagnosis of the sensor interface are passed on to the diagnosis manager, the diagnosis manager still receiving results of the diagnosis function, the results of the diagnosis function being calculated from residuals determined by the observer, with a switch to a substitute or model value in the observer is carried out if necessary by means of a decision strategy via the reconfigurator. Device according to one of the Claims 1 or 2 , wherein the functions assigned to the hardware access layer include hardware-specific drivers for each sensor for reading out the input interfaces and each sensor functions for diagnosing the state of the respective connected sensors. Device according to one of the Claims 1 , 2 or 3 , the sensor signal conversion layer being assigned functions for carrying out electrical diagnoses. Device according to one of the Claims 2 , 3 or 4th If redundant sensor information is available for a measured value, mutual plausibility checks of the sensor signals are carried out by means of the functions assigned to the sensor signal conversion layer for performing electrical diagnoses, in order then to provide a single physical value. Device according to one of the Claims 1 until 5 , wherein the sensor interface is part of a modular structure of a computer program code for controlling and regulating a drive system from several blocks, with at least one block for a.) a sensor interface, b.) an actuator interface, c.) a communication -Interface, d.) An observer / signal processing, e.) A diagnosis manager, f.) A reconfigurator, g.) A diagnosis function, h.) A controller, is provided, with the blocks a.) To h. ) are connected to each other for the exchange of data / information, whereby the blocks a.) to h.) are assigned functions, depending on the drive concept of the underlying drive system and / or the number / properties of the sensors or actuators used that affect the blocks a.) to h.) assigned functions can be specified.

Images