DE102009011157A1 - Drive system e.g. internal combustion engine, controlling and/or regulating device for hybrid vehicle, has sensor interface connected with sensors, where functions are determined based on drive principle and characteristics of sensors - Google Patents

Abstract

It is an object of the present invention to provide a device for controlling and regulating a drive system, which is kept so general that it is applicable for arbitrarily complex drive systems, with as little change required when changing the drive system or an associated change in the sensors and actuators arises. This object is achieved by a device for controlling and regulating a drive system comprising a computer program code, wherein the computer program code is modularly structured from a plurality of blocks, wherein in each case at least one block for a sensor interface, an actuator interface, a communication interface , an observer / signal processing, a diagnostic manager, a reconfigurator, a diagnostic function and a controller is provided, these blocks are connected to the exchange of data / information with the blocks are assigned functions, depending on the drive concept of Underlying drive system and / or the number / characteristics of the sensors or actuators used which are assigned to the blocks associated functions.

Description

The The present invention relates to an apparatus for controlling and Control of a drive system according to the features of claim 1.

From the DE 100 44 319 A1 it is already known to use embedded software solutions for controlling and / or regulating a vehicle, whereby so-called basic functions and operating functions are used, the basic functions including, inter alia, so-called core functions and driver software, ie functions that are specific to the control unit, wherein the operating functions include functions, determine the actual performance of the vehicle, the basic functions and the operating functions are separated from each other so that an addition or replacement of operating functions is possible without the basic functions must be changed. However, if, for example, in the context of a further development of the drive system of a motor vehicle a change in the sensors and actuators is to be assumed that both changes in the operating functions and changes in the basic functions are required.

task

It is therefore an object of the present invention, a device for To provide control and regulation of a drive system, which so general is that they are for any complex drive systems is applicable, wherein at a change of the drive system or an associated change in the sensors and actuators the least possible change is required.

solution

• a.) eine Sensor-Schnittstelle,
• b.) eine Aktuator-Schnittstelle,
• c.) eine Kommunikations-Schnittstelle,
• d.) einen Beobachter/eine Signalverarbeitung,
• e.) einen Diagnose-Manager,
• f.) einen Rekonfigurator,
• g.) eine Diagnosefunktion,
• 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. Erfindungsgemäß vorteilhaft entsteht bei einem Wechsel des Antriebssystems und einer im Allgemeinen damit verbundenen Änderung der Sensorik und Aktuatorik wenig Änderungsbedarf hinsichtlich der zu Grunde liegenden Vorrichtung zur Steuerung und/oder Regelung, da durch den in der erfindungsgemäßen modularen Struktur vorgesehenen Beobachter gemäß Block d.) im Zusammenwirken mit der Sensor-Schnittstelle gemäß Block a.) und dem Controller gemäß Block h.) eine Abstraktion der Sensorik vorgenommen und die Sensorik von den Reglerfunktionen im Controller gemäß Block h.) entkoppelt wird. Wenn sich beispielsweise im Zuge eines Projektwechsels die Sensorkonfiguration ändert, müssen nur die Funktionen, die Block d.) zugeordnet sind, angepasst werden. Die Funktionen, die dem Block h.) zugeordnet sind, bleiben unberührt, weil die festgelegte Schnittstelle zwischen Block d.) und Block h.) unverändert bleibt. Außerdem ist durch das Zusammenwirken des Controllers gemäß Block h.) mit der Aktuator-Schnittstelle gemäß Block b.) in der erfindungsgemäßen modularen Struktur auf vorteilhafte Weise eine Entkopplung von Reglerfunktionen und verwendetem Aktuator möglich. Erfindungsgemäß 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 einem 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. Erfindungsgemäß wird unter einem Block ein übergeordnetes Architektur- oder Strukturelement verstanden, das als Behälter für Module und Funktionen dient. Als Funktion werden erfindungsgemäß 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.This object is achieved by a device for controlling and regulating a drive system comprising a computer program code, wherein the computer program code is modularly structured from a plurality of blocks, wherein in each case at least one block for

• a.) a sensor interface,
• b.) an actuator interface,
• c.) a communication interface,
• d.) an observer / signal processing,
• e.) a diagnostic manager,
• f.) a reconfigurator,
• g.) a diagnostic function,
• h.) a controller,

The blocks a.) to h.) are connected to each other for the exchange of data / information, wherein the blocks a.) to h.) Functions are assigned, depending on the drive concept of the underlying drive system and / or the number / characteristics of the sensors or actuators used, the blocks a.) to h.) assigned functions are determined. In other words, blocks a.) To h.) Serve as containers or containers for the functions necessary for controlling and regulating the drive system, the contents of the containers depending on the drive concept of the underlying drive system, ie in the context of a vehicle application, for example an Otto , Diesel or hybrid drive and / or the number / characteristics of the sensors or actuators used varies. In accordance with the invention, when the drive system is changed and a change in the sensors and actuators associated therewith is required, there is little need for modification with regard to the underlying control and / or regulation device, as provided by the observer according to block d Cooperation with the sensor interface according to block a.) And the controller according to block h.) Made an abstraction of the sensor and the sensor is decoupled from the controller functions in the controller block h.). If, for example, the sensor configuration changes in the course of a project change, only the functions that are assigned to block d.) Need to be adapted. The functions assigned to block h.) Remain unaffected because the fixed interface between block d.) And block h.) Remains unchanged. In addition, by the interaction of the controller according to block h.) With the actuator interface according to block b.) In the modular structure according to the invention in an advantageous manner a decoupling of controller functions and actuator used. According to the invention, a generally held modular overall structure is accordingly formed by the arrangement and connection of the blocks a.) To h.), With which various drive concepts, for example a gasoline, diesel or hybrid drive of a vehicle, can be controlled and / or regulated , wherein the blocks a.) to h.) Act as a container for the necessary functions, depending on the drive concept, the content of the container varies. For the purposes of the present invention, a drive system may, inter alia, be 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 obtaining electrical energy or also the general term for the entire drive train of a vehicle. According to the invention, a block is understood to mean a superordinate architectural or structural element which serves as a container for modules and functions. As a function of the invention elementary, definable components of the control and regulation or a Software for control and regulation, which fulfill a defined task and have exactly specified interfaces. For example, a so-called idle speed controller of an internal combustion engine as the drive system of a motor vehicle is a function. A module also refers to a set of thematically related functions. For example, the module "drive train coordinator" contains all the functions necessary for controlling and regulating the drive train of a motor vehicle, including, inter alia, an internal combustion engine and a transmission. As far as technically possible, a module corresponds to a physically describable hardware component, for example the air system or the fuel system of an internal combustion engine.

embodiment

Further advantageous embodiments of the present invention are the subsequent embodiment and the dependent To claim.

in this connection demonstrate:

1 : the modular structure according to the invention for controlling and regulating a drive system,

2 : the modular structure according to the invention as part of a device for controlling and regulating a drive system from an AUTO-SAR point of view,

3 : Details of the sensor interface,

4 : the representation of the signal flow from a converted sensor voltage value to the actual value,

5 : Details of the actuator interface,

6 : Details on signal conditioning,

7 : the principle of a state observer,

8th : Observer details / signal processing,

9 : Details on communication within the observer / signal processing,

10 : Details about a signal selection,

11 : Details of the Diagnostics Manager,

12 : internal communication / signal flow within the diagnostics manager,

13 : the signal flow within the controller,

14 : Details on the diagnostic function,

15 : the additional module level in the diagnostic function,

16 : the communication within the diagnostic function,

17 : Details about the reconfigurator,

18 : Details on reconfiguration strategies.

According to 1 is the modular structure according to the invention for controlling and regulating a drive system comprising the blocks a.) to h.) And other blocks i.) to l.) Is shown. The block a.) Represents in the structure according to the invention a sensor interface which is responsible for the basic processing of sensor signals, wherein functions associated with the block a.) Serve to drive hardware components for the detection of signals, so for example perform an A / D conversion, conversions of electrical signals into physical quantities, that is, for example, to convert a voltage into a pressure and to perform a hardware-related basic diagnosis and plausibility of the measured signals. The functions assigned to block a.) Are hardware-oriented and act as a hardware abstraction layer. The block a.) Is connected to sensors for exchanging information / data and to the block d.), Ie the observer or the signal processing, as indicated by the two bold arrows. Inputs to block a.) Are the sampled, quantized electrical signals from the sensors, which are processed by the functions associated with block a.) So that the outputs of block a.) Are converted into physical quantities, such as pressure or temperature , converted electrical sensor signals, which are supplied to the block d.), wherein by means of the observer / the signal processing, a correction / adaptation of the detected signal or a comparison with modeled signal values can take place. In addition, the block a.) For the exchange of information / data with the block e.), Ie the diagnostic manager, connected, as indicated by the arrow, and depending on the result of the performed in block a.) Basic diagnosis and plausibility of the measured signals by means of the diagnostic manager in block e.) An administration is carried out, for example, a dropping of error information in a non-volatile memory and optionally to the outside via a diagnosis setester. In practice, the provision of the block a.) In conjunction with the blocks d.) And e.) The advantage that when a sensor of a particular manufacturer is replaced by a sensor from another manufacturer, only the block a.), Ie the sensor interface and no other peripheries of the device for controlling and regulating the drive system are influenced, thus remain unchanged.

Of the Block b.) Provides in the structure according to the invention The actuator interface is for final processing of actuating signals and their forwarding to the actuators or Power amplifiers is responsible. The block b.) Is next to the respective one Actuators with the block h.), So the controller, for replacement connected by data / information, as indicated by the bold Arrow indicated. In block b.) Control signals are read in, which may be in logical or physical units and which are formed in the block h.). The block b.) Associated Functions convert these actuating signals into signals in suitable form so that they are forwarded to output stages for controlling the actuators can be, as by the other bold arrow indicated. The functions associated with block b.) Are mainly the task of making a final processing of actuating signals, to build a driver for the power amp hardware, a Driver for actuator hardware and perform power amp diagnostics. Block b.) Is also used to exchange information / data the block e.), ie the diagnostic manager, as connected by the Arrow indicated, depending on the result the diagnostics of the output stages carried out in block b.) or the actuators by means of the diagnostic manager in Block e.) An administration takes place, for example, a deposit of a Error information in a non-volatile memory and, if necessary a communication of the error information to the outside via a diagnostic tester. In addition, block b.) Is for replacement of information / data with the block d.), ie the observer Signal processing, connected as indicated by the two arrows, in particular, current modeled / observed process variables or measured signals from block d.) to block b.) become.

According to the invention advantageous takes place with the help of the division into block b.) and block h.) one Decoupling of controller functions and used actuator, respectively can by means of the division of the block h.), the controller functions are assigned, and the block b.) controller functions independently realized by the actuator used. An example of this is a so-called rail pressure control to set a specific Pressure value in the rail of the injection system of an internal combustion engine. The block h.) Assigned controller function generates as an abstract control variable a nominal volume flow through the high-pressure pump. The actuator interface, So block b.), calculated from this abstract manipulated variable a control of the actuator. For example, the latter can be around a quantity control valve or in another concept around a suction side Three way valve act. The controller function thus remains independent of Pump concept and can for different fuel systems be used.

Of the Block c.) Provides in the structure according to the invention a communication interface that connects to others Devices for controlling and regulating a drive system, So other control devices or units, allows one protocol-based communication, such as CAN, CCP, XCP, FlexRay or diagnostic tester. the Block c.) Are thus assigned functions that facilitate the exchange data or messages with other communication partners. Furthermore, here is the CAN monitoring, for example regarding timeouts, to accommodate. The block c.) Is accordingly with external communication networks, such as the CAN bus connected, as indicated by the double arrow. Besides, block is c.) for communication within the invention Structure with the block h.), Ie the controller, the block d.), So the observer / the signal processing and the block e.), So connected to the diagnostic manager, as indicated by the arrows. about the connection of the block c.) to the block e.) further data / information regarding diagnostic results of others Control units or units of the drive system transmitted be as indicated by the arrow / double arrow. As input variables of the block c.) can therefore be summarized, external, for example via CAN received signals, measured or modeled signals from block d.) to be sent further, control signals from block h.), for example, sent to another controller should be and managed by block e.) Diagnostic results, such as for example, error memory entries. As output variables of block c.) can be summarized on the one hand, signals that be sent outwards, such as measured / modeled Signals from block d.) To the other control signals from the block h.) and further diagnostic results from block e.). output signals block c.) are also external variables read in, such as the vehicle raw speed or torque setpoints, which are forwarded via block c.) to block d.).

In the structure according to the invention, the block d.), Ie the observer / the signal processing, is an essential element which is accessible via the rei ne basic control function of a state observer goes beyond. 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 measurement and model referred to as residuum is 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 drive and vehicle, the necessary connections are as arrows in 1 shown. For the realization of model-based diagnoses, in particular block g.) Is supplied with the observer residuals. The actual state is composed of measured signals, observed quantities and further variables calculated from measurements, observations and the further block d.) Of the signals provided. These may be value-continuous signals such as speeds or pressures, but also value-discrete information such as the current operating mode of an internal combustion engine or a status bit indicating the operational readiness of a lambda probe. Thus, 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 entire system, but also further information is provided to the system. An example of such information is the cylinder filling, which is calculated from state variables such as intake manifold pressure, etc.

In other words, the functions associated with the block d.) Have the task of observing the current actual state of the drive system to be controlled and regulated by means of models. For example, 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 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 1 shown. From this comparison, the so-called residuals emerge, with the help of which an observer feedback is realized, which corrects the modeled state variables. Residual is a calculated error, for example between model and measurement. If a measurable quantity is calculated using a mathematical model, then the difference between the measured and modeled value represents the residual. Another task of the functions associated with the block d.) Is the observation of the system states, with these observed states in addition can be used to use non-measurable variables in the control and regulation. 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 associated with the block d.) To provide the functions associated with the block h.) And the block g.) With the information about the actual state of the system and the residuals. Block d.) With block h.) And block g.) Is connected to the exchange of data / information so that measured and / or modeled / observed signals can be transmitted, as in 1 indicated by the arrows, wherein the measured and / or modeled / observed signals can also be combined in a common bus. Furthermore block d.) Allows the functions associated with the block h.), Ie the controller, to be implemented independently of the sensor configuration. Such a decoupling or abstraction of the sensor advantageously effects that when the sensor configuration changes, for example when the drive concept changes, due to the fixed interface between block d.) And block h.), Only the functions corresponding to block d.) are assigned, must be changed, and not the block h.) assigned functions. A change in the sensor configuration is therefore not reflected in a change in the controller functions. In other words, the observer takes an abstraction of the sensor system according to block d.) And decouples this from the controller functions in the controller, that is from block h.). If, for example, the sensor configuration changes in the course of a project change, only the functions that are assigned to block d.) Need to be adapted. The functions assigned to block h.) Remain unaffected because the fixed interface between block d.) And block h.) Remains unchanged. As already explained, the block d.) For the exchange of data / information is further connected to block b.), Wherein in particular modeled / observed or also measured signals are transmitted from the block d.) To the block b.), As by the arrows indicated.

Another functionality of block d.) Is the realization 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.), Ie the observer, can naturally be assigned to individual hardware components. So there is in connection with a used combustion engine an intake manifold model, a rail model and so on. So there is always a so-called "component view" obtained, which allows a quick assignment of modules and functions 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 standard quality. So not everything is always measurable in technical systems. For a higher-order system, the control quality can be significantly improved if, in addition to the output feedback, the internal system states are also used for the control signal generation. An observer, as in block d.), Offers the possibility of reconstructing internal system states without additional sensors. By returning the observed states, the control quality can be improved. Thus, all internal system states are detected by the observer in accordance with block d.) And are available for the control. In this way, powerful modern methods, such as state controllers, can be easily integrated. The use of this additional information can lead to higher quality control. On the other hand, there is an improvement in the quality of diagnosis. Thus, based on an observer, as in block d.), Estimated states are compared with measured signals. If, at runtime, the residuals between observed and measured signals exceed previously defined threshold values, it is possible to conclude that an error has occurred. Residuals and dynamic models can be used to obtain more meaningful diagnostic results, such as error detection, pinpointing, and quantification. Pinpointing describes the identification of the smallest replaceable defective component of the drive system. Thus, all sensor sizes can be compared with corresponding model sizes. The resulting residuals can be used for fault diagnosis. Efficient model-based diagnostic techniques can be realized in this way. These methods are better in terms of depth of diagnosis than simple signal-based methods currently used. Furthermore, there is an increased fault tolerance and reliability. Thus, observer functions, as per block d.), Can be regarded as virtual sensors that provide replacement values for the failed sensors in the event of an error. Thus, 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 block d.), Can be considered as virtual replacement sensors. For example, depending on the result of an observability analysis, it is possible to save some real sensors. These savings are at the expense of reliability and fault tolerance. At this point, a trade off between fault tolerance and sensor cost should be achieved. In addition, block d.) Is connected to block c.), Ie the communication interface, for the exchange of data / information, as indicated by the double arrow. Thus, via the block c.) External signals, such as the vehicle raw speed, to block d.) Are transmitted and forward to be sent measured and modeled signals from block d.) To block c.) Forwarded. Block d.) Is also connected to block g.), Ie the diagnostic function, for the exchange of data / information, as indicated by the two arrows. Thus, measured / modeled signals can be passed from block d.) To block g.) To make an active diagnosis. In addition, block d.) Is connected to block e.) For exchanging data / information, as indicated by the arrow / double arrow. Thus, release information or release requirements, for example, for model adaptation, to the block e.) Are transmitted. In addition, block d.) Is connected to block f.) For exchanging data / information, as indicated by the arrow, where reconfiguration information can be transmitted from block f.) To block d.), Where block f.) Functions are assigned, which correspond to a "reconfiguration", ie a switching of signals, structures or parameters at runtime, which are carried out in dependence on diagnostic results.

In the structure according to the invention, the block e.) Represents the diagnostic manager to which functions are assigned, which have the task of administering diagnostic results 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 diagnostic results, the management of the workshop diagnostics, the MIL management, the error recovery, as well as the fulfillment of other demands imposed by the legislator are tasks of the functions associated with 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 of block e.) Are requirements, for example, after releases for operating mode switching, from block h.), So the controller. Input variables of block e.) Are furthermore requirements, for example for approvals for model adaptation, from block d.), Ie the observer. Input variables of block e.) Are also diagnostic states and results of the block g.), So the diagnostic function. Input variables of block e.) Are also diagnostic states and results of the block c.), So the communication interface. Input variables are also diagnostic states and results from block a.), Ie the sensor interface. Input variables are ultimately also diagnosis status and results from block b.), ie the actuator interface. Outputs of block e.) Are releases to the block h.), D.) And f.) As well as releases and blockages to the block g.) As well as error storage information to the block c.).

In the structure of the invention provides the block f.) represent the reconfigurator to which functions are assigned have the task, in case of error, a reconfiguration of the block d.) and / or block h.). The term "reconfiguration" is used According to the invention a signal, structure or parameter switching understood at runtime. The reconfiguration is based on the Diagnostic results. If, for example, in a diagnostic function a sensor is detected as faulty, then the block f.) assigned functions the necessary signal and structure switching in block d.). Becomes an actuator or other system component detected as faulty, then block d.) as well as block h.) be reconfigured accordingly. The block f.) Is for replacement data / information with the block e.), the block d.) and the Block h.), As indicated by the arrows or the double arrow indicated. Input variables of the block f.) Are the diagnostic information managed by block e.). outputs block f.) are reconfiguration requests made to the block h.) and / or block d.). According to the invention leads the use of a reconfigurator to increase the Fault tolerance of the entire system or the device for controlling and regulating a drive system, as in the event of a fault at runtime, triggered by the reconfigurator, from a measured value can be switched to a model value.

In the structure of the invention provides the block g.) a diagnostic function, which in turn assigned functions are those who have the task of making a diagnosis to be able to. So are in block g.) Signal and / or Model-based diagnostic functions. The necessary information about System states and residuals used as the basis for these diagnostic functions are provided by block d.). The diagnostic functions also have the option of the Control signals or setpoints in block h.) To influence a to perform 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. Input variables of the block g.) Are the measured and modeled signals including the residuals from block d.) and the diagnostic enable information of block e.). outputs of the block g.) are diagnostic results and status information, which are transmitted to block e.) and setpoint manipulations for carrying out active diagnoses, which are sent to block h.) become.

In the structure of the invention provides the block h.) a controller, which in turn functions are assigned, which have the task of generating setpoints and control signals, to make strategic decisions and to coordinate the Components, ie coordination of functions and modules, to a particular hardware component, such as the fresh air or Exhaust system of a vehicle belong. As a basis for These tasks primarily serve those information that comes from the block d.). In the block h.) Can the following Categories of functions, such as governor functions, Controls, setpoint generation, strategic decision, such as For example, a mode switch or coordination of Powertrain components. The functions contained in block h.) can be as well as the block d.) The individual hardware components assign. The block h.) Is for exchanging data / information with the blocks b.), c.), d.), e.), f.), g.) and h.), as by the arrows, the 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 transmission, which arrive over the block c.) as well as the measured and / or modeled signals from block d.). outputs are the control signals going to block b.) and block c.), Adaptation values and information about parking stops to block g.) as well as release requests to block e.).

In summary, the modular structure according to the invention is kept so general that it remains applicable to more complex drive systems. For example, with regard to the operation of motor vehicles, active braking or hybrid drive concepts with their specific actuators and system components can be readily implemented. For this purpose, no changes are required to the structure, the development effort is limited solely to the functions assigned to the individual blocks, for example regarding the drive management in block h.). The level of detail of this description takes into account the claim to generality. Thus, no descriptions of functions, implementation aspects, rasters, operating states are disclosed. Rather, the purpose as well as the principle cooperation of the structure blocks a.) To h.) Defined in the following section shall be described. These structure blocks a.) To h.) Are the containers for the functions and modules to be developed. Which of these preferred executed as software components in the special case of a particular drive fill these containers is al Only depending on the technical needs. Thus, for example, only in the event that in the context of an application in the field of internal combustion engines, a secondary air pump is present in the system, also a corresponding diagnostic function is incorporated into the control unit code.

In the 1 Blocks a.) to h.) which describe the system architecture now include a plurality of modules and functions. These, in turn, generally work with different time grids. Basically, the following calculation rasters are to be provided. Crank angle synchronous grid, such as a firing segment synchronous grid of an internal combustion engine and with respect to a high-pressure injection pump of an internal combustion engine, a conveyor-synchronous grid. In addition, it is expedient to provide time-synchronized rasters, for example 1 ms, 10 ms, 20 ms, 100 ms and so on. Also conceivable are event-controlled tasks, such as the execution of the reconfiguration only in the case of a corresponding error. Care should be taken that the signals read in from block a.) Are adequately sampled so that no aliasing occurs. It should also be noted that when resampling signals having a longer sampling time, anti-aliasing filters are to be provided if there is a significant energy content above the Nyquist frequency.

According to 1 The structure according to the invention also comprises block i.), which contains classes of functions in a library which are called at runtime. It may be here z. Example, an optimizer, a recursive estimation algorithm o. Ä. Act.

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

According to 1 the structure according to the invention furthermore comprises the block k.), which represents the interface to an application system, ie the hardware, communication and software required for this purpose. This block is to ensure that the parameters of the functions can be adjusted on the basis of a PC via a standard interface and that signals such as measured values and calculated signals can be recorded from the control unit.

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

Finally, the structure of the invention further comprises the block l.), Which serves a not further described monitoring of the control unit with respect to impermissible acceleration of an underlying vehicle. The architecture according to the invention provides for the grouping of functions of the block h.) And the block d.), As far as possible of the other blocks, into physically oriented modules. A subdivision into modules, which is, as it were, universal for the most diverse combustion engines, is the following:

• 1. Air System (Air System)
• 2. Fuel System
• 3. combustion process (combustion)
• 4. Exhaust System
• 5. Powertrain
• 6. Cooling system (Thermal System)
• 7. Electrical System (Electrical System)

in the Towards an extension of the respective control unit software For other drive concepts, the above list can be extended accordingly.

The Architecture allows different operating states besides the normal operation, z. As the initialization and the caster. In the operating state "Initialization" all ECU functions initialized. In the operating state "Caster" Any stationary adaptions carried out, adaptation values written in nonvolatile memory and so on. The detailed definition of these and possible others Operating conditions depend on the ones to be developed Functions off. Because the architecture is essentially signal flows does not contradict any further operating conditions represents.

Expressly not part of the architecture described here are the following Aspects. Regarding the ECU hardware is the Software architecture independent and should be based on different To realize target platforms. Regarding the engine and driveline hardware the software architecture should cover a broad spectrum in particular of Cover vehicle concepts. In connection with the implementation of the Functions can not and should not be anticipated for functional development. The architectural description has a general character and should not depend on the implementation of the necessary functions but rather all technically meaningful realizations allow.

According to 2 For example, the modular structure according to the invention can also be represented as part of a device for controlling and regulating a drive system from the point of view of the association for the creation of open standards for software architectures of motor vehicles, AUTOSAR. The AUTOSAR standard provides for a subdivision of the ECU software into the application layer and the infrastructure layer. These two layers exchange data via the so-called runtime environment (RTE). The latter forms an interface, which is a decoupling application software from the hardware. Also within the application layer is communicated via the RTE. There are both architecture blocks whose contents are located exclusively above the RTE (eg the controller and the observer) as well as blocks containing portions above and below the RTE (eg the actuator interface, the sensor interface). Interface, the diagnostics manager, the library).

According to 3 is the block a.), So the sensor interface, 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. The sensor interface contains functions for the basic processing of the sensor raw signals sent to the control unit by the sensors. The sensor interface is modular in design to allow easy adaptation of the software to changes in the sensor hardware. Input signals of the sensor interface are the output signals of the sensors. The interface is structured by two layers. At the lowest level is the hardware access layer (Hardware Access). This contains the hardware-specific drivers for reading out the input interfaces (hardware drivers). These are, for example, drivers for access to digital and analog converter (ADC) of the ECU hardware used. In addition, diagnostics service (inp modules or input modules) are supplied by the layer with regard to the hardware status, these usually being status words or binary values. Above the hardware access layer is the sensor signal conversion layer (sensor conversion). It includes sensor functions that convert the sensor raw data supplied by the hardware access level into physical sensor values (transformation) and carry out a simple electrical diagnosis (low-level diagnosis, range check, plausibility). The lowest level of the sensor interface is part of the basic software of the ECU according to AUTOSAR. Conceptually, the hardware access layer is disconnected 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 diagnostics performed in the sensor interface are summarized in the SensorStatusBus to block e.), Ie the diagnostics manager. These external interfaces can be implemented as part of an implementation, for example in SIMULINK ^® , via signal buses.

In The hardware access layer is used to control hardware components for signal acquisition (A / D converter, digital I / Os). The voltage values supplied by the hardware driver are determined by the in The sensor conversion layer contains conversion functions further processed. The conversion of the electrical Signals in physical quantities such as pressure or Temperature. The sensor values are from the sensor interface in the functionally required smallest time grid to the Observer, that is to block d.), Passed on. additional The task of the sensor conversion layer is the implementation Hardware-related basic diagnoses and, if necessary, implementation a signal plausibility check. The diagnosis includes simple electrical diagnostics (signal range check of the incoming sensor voltages). Plausibility checks are only possible in the sensor interface performed when redundant for a measured value Sensor information are available, such. For example the throttle opening angle by two position sensors. Because these functions are hardware-proximate, they are supposed to be a hardware abstraction layer serve. If a sensor S of the company ABC with another sensor S is the company XYZ exchanged, then only the sensor interface function S be influenced by it. Therefore, between conversion routines, which are located on one level of the sensor interface, no cross-couplings exist.

According to 4 Furthermore, a basic representation of the signal flow from the converted sensor voltage value supplied by the ADC to the actual value is listed, which is then used by the functional software or supplied to block b.) and / or block h.). After processing the sensor signal through the sensor interface, the physical sensor actual value is forwarded to the observer in block d.). In the observer, the value can be corrected using a suitable adaptation strategy. The sensor value is then forwarded to a selection block that can be used to switch between the backup value, a modeled value, the measured correction and an additionally filtered sensor value (filter). The results of the hardware diagnostics and low-level diagnostics of the sensor interface are passed on to the diagnostics manager or block e.). In addition, the diagnostics manager receives the results of the diagnoses calculated from the observer residuals (Model Value minus Actual Value) in block g.). With the aid of a decision strategy, a switchover to a substitute or model value in the observer is then optionally carried out via the reconfigurator in block f.). A feature of the sensor interface is that a conversion routine for calculating the physical sensor measured value is available for each converted sensor raw value. Another feature of the sensor interface is that an electrical diagnostic can be performed for each analog sensor value. A still further feature of the sensor interface is that the transmission of the sensor values can be performed in the smallest time frame required on the function side, wherein the increase in the time resolution requires a function-side requirement. A further feature of the sensor interface is that signal filtering can then be performed in the sensor interface, if only a filtered value of all functions is needed that use this value in the smallest time frame. In other words, the filtering is carried out in the sensor interface only if the sensor value in the smallest time interval is not needed as an unfiltered signal in the system by any function. A still further feature of the sensor interface is that if there are two sensors of the same kind for detecting a physical signal, such as two position sensors of the accelerator pedal of a motor vehicle, then the corresponding conversion routine should, if possible, plausibility and mutually plausibility of the redundant signals provide a single physical value. Yet another feature of the sensor interface is that no cross-couplings are allowed between the sensor interface conversion routines, such as using the speed signal for the boost pressure sensor conversion routine. This should support the easy interchangeability of sensors.

The interfaces within block a.) Are characterized as follows. In the communication of the layers, the signals are grouped and sent, for example, via buses between the blocks, so communication between the layers of the sensor interface is carried out, for example, when implemented in Simulink ^® via buses which allow a clear signal grouping. This does not include the possibility to use other implementation tools such as ASCET ^® . In this case, signal grouping can be done by using appropriate identifiers for the signals to be declared as messages, if necessary. The input signals provided by the hardware driver are grouped into buses and passed to the conversion layer. Thus, analog sensor signals are grouped into a bus. Also, digital sensor signals, such as bit sizes, duty cycles, frequencies, periods, are grouped into a bus. In addition, crankshaft and camshaft angular sensor input signals are grouped into a bus. The diagnostic results of the hardware access layer are summarized in a bus and passed on to higher layers.

The Within the block a.) to be realized functions can be characterize as follows. The sensor interface includes conversion routines for the following sensor signal types: for analogue 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 Hallgeber, for pulse width modulated digital sensor signals, such as from an HFM sensor, for special digital sensor signals, such as for example, from an oil level and temperature sensor. In the case of analog sensor signal conversion routines and also special analogue sensor signals and periodic digital ones Sensor signals will be a low-level diagnostic with verification of Range limits of the sensor signal performed. For measured quantities, which are received by two sensors of the same kind, for example Throttle position sensors or accelerator pedal sensors becomes a mutual plausibility of the signals carried out and one of the signals in the sensor bus to the observer in block d.) Forwarded. In the hardware access layer are hardware-specific routines and drivers for accessing input modules of the hardware and the Reading out hardware-related status information. The Functions have a high hardware dependency. she provide access to analog and digital input modules and special input modules, such as for the evaluation of Knock and lambda probe signals. The evaluation of a temperature sensor in the sensor interface, the processing of a sensor signal exemplify. The analogue voltage signal of the sensor becomes from the hardware access layer to the conversion routine passed. In addition, status information about passed the state of the A / D converter and the hardware. The calculation a temperature value then takes place for example via a characteristic from the read voltage value. In the conversion routine takes place additionally a check of the signal range with Return of the diagnostic result. The status information are measured in the SensorStatusBus and the measured temperature value in the SensorBus passed.

According to 5 is the block b.), So the actuator interface, shown in detail. On the one hand, the actuator interface contains functions that are responsible for processing control signals and provide these as input signals to the power amplifier drivers. On the other hand, the actuator interface also includes hardware-specific functions that generate additional driver signals necessary for the control of output stages, such as the charging time of an ignition coil Internal combustion engine. The actuator interface basically consists of two hardware-specific levels. In one level, the control signals coming from block h.), Ie the controller, are converted via the ControlBus into input signals for the hardware-related drivers, which are basically the signal processing level. This level is structured analogously to block d.) And block h.) Into the following hierarchies: Air System, Fuel System, Powertrain, Thermal System, Exhaust System and Combustion System. The second level of the actuator interface is the driver level as an interface to the peripherally connected power amplifiers. It is part of the basic ECU software after AUTOSAR. In spirit, the two levels are separated by the Runtime Enviroment (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 led out of the actuator interface. The ControlBus, which is generated in block h.), Contains all physical and logical control signals of all controllers and controllers. This also includes bits for the activation of the power amplifiers. The system bus, which is assembled in block d.), Is composed of the measured and / or modeled signals or actual values. The ActuatorStatusBus contains the status signals of all power amplifiers, which are provided as output signals of output stage diagnostics functions, as well as the status bits, which are generated as part of a value range check after signal conditioning. The status signals of the output stages include signals which, for example, reproduce information about short circuits to ground or to the plus of the individual outputs of the output stage. The status signals combined in the actuator interface to the ActuatorStatusBus are made available to the diagnostics manager in block e.) For further processing. If it is necessary, in the actuator interface before the assembly of the ActuatorStatusBusses first a conversion of the individual dependent of the system manufacturer diagnostic signals in a predetermined by the diagnostic manager in block e.) Format be performed or is not an interface for the Diagnosis of the power amplifiers provided, so instead a previously defined replacement signal is generated at this point and further used. For the implementation of the mentioned data buses, for example, so-called Bus Objects offer in Simulink ^® to comply as the demand for data consistency appropriately.

The Signal conditioning converts the physical control signals if necessary with the help of further information in input signals for the power amp driver. Depending on the connected actuator there is a software component for each steller the signal conversion. When replacing an actuator A of the company ABC against another of the company XYZ are accordingly also the Software component for signal processing as well as the associated drivers for the controller to be replaced affected by the exchange and adapt. As a result, cross-couplings among the individual functions within the signal processing or the driver level is not allowed, so that when replacing / eliminating of actuators the interfaces of other software functions are not need to be adjusted. Not applicable Actuator xyz, so also eliminates the associated software component for converting the physical control signal and the power amplifier driver for this actuator xyz. In this case, need the associated software functions in block h.) and if necessary in block d.). It behaves accordingly itself when an actuator is added. For the control of the additional / new actuator must be in the actuator interface a corresponding software component for signal conditioning and a driver component for driving the associated ones Power amplifier to be added. The block h.), Ie the controller, is to be adapted so that for this added Actuator also generates a corresponding manipulated variable becomes.

The Interfaces within block b.) Are characterized as follows. If from the respective software functions from the signal processing level only pass individual driver signals to the corresponding drivers be, serve only signals as interfaces. Before calling a software component to process a physical signal are thus first to be converted Control signal from the ControlBus and the for the conversion and possibly further signal processing (scaling) to select required signals from the system bus. The available as a result of the signal conditioning Output signal is output from the corresponding output stage driver Driver level immediately provided for further processing. On the other hand, several signals have to be transferred to an output stage driver these signals are still within the signal conditioning level together as a bus and the power amp driver as a bus to hand over. Thus is also a consistent data transfer even if the signal conditioning and the Amplifier drivers are called in different tasks.

The functions to be implemented within block b.) Can be characterized as follows. This is in the 6 the signal processing is illustrated as an example for the actuator xyz. Immediately before calling the associated software compo For signal conditioning, the desired actuating signal and, if present, an enable bit for activating the associated output stage are selected from the ControlBus. If further information, such as the speed or battery voltage, is required for the preparation, these must be provided 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), taking into account the physical dimension, signal conditioning is performed by a generally non-linear mathematical combination of the selected signals. The processed signal is then checked for its value range, wherein the minimum (y _min ) and the maximum permissible value (y _max ) depend on the actuator to be controlled and both values are 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 activation of the actuator has not been enabled, depending on the driver signal conditioning either is not required or the signal to be processed is set to a specific value (eg charging time of the ignition coils = 0 s if not to be ignited). The driver input signals and the enable bit set to FALSE are transferred as a bus directly to the output stage driver. If it is necessary, in any software component for signal processing and a conversion of the enable bit in a predetermined by the system manufacturer format are performed or provided by the system manufacturer no interface for the activation of individual power amplifiers, then the enable bit for these power amplifiers not forwarded to the driver level. An example will now be used to demonstrate signal conditioning. The rail pressure regulator as part of the block h.), So the controller calculated depending on the prevailing operating condition to be pumped amount of fuel in, for example, liters per hour. This is converted in the actuator interface with an increase in further hardware-specific information, such as the number and contour of the cams, the inductance of coils, the battery voltage, first in an angular range and using the engine speed in a period of time. Start of the control in the form of an angle and the duration of the control are coming from the actuator interface input variables of the output stage driver, which thus set 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 correspondingly limited. Finally, the signal to drive the power amp is generated by the power amp driver as part of the driver-level complex driver. If, for example, the valve characteristic of the quantity control valve changes during use and can be described quantitatively from the system bus with the aid of further variables, a corrective intervention is possible with the present architecture as part of signal conditioning 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 sometimes be generated without information from the SystemBus or individual driver inputs exclusively from signals from the SystemBus, such as the charging time of the ignition coils.

The block d.), Ie the observer / the signal processing, will be described in detail at this point. The functions of this block have the task of the momen tanen actual state of the system to be controlled and regulated, in particular an internal combustion engine in a motor vehicle to observe. This observation takes place model-based. 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 environmental conditions. Modeled measurable states are compared with measurement signals and residuals are generated. On the basis of these residuals, an observer feedback is realized in order to correct the modeled state variables. The principle of a state observer is in the 7 shown. As a status observer, the observer / signal processing according to block d.) Implements the following functions. On the one hand, this is the observation of the system states, on the one hand, these observed states can be used to use non-measurable variables for control and regulation. On the other hand, in the event of a fault, the observed states can be used as substitute values for the measurement signals. The observer functions are to provide the functions of the block h.), Ie of the controller, and the block g.), Ie the diagnostic function, with the information about the current system state and with residuals. As far as possible, the block d.), Ie the observer, should ensure that the functions of the block h.) Can be realized independently of the sensor configuration. In addition, the observer / the signal processing according to block d.) Model or signal-based sensor adaptation process realize that reduce the influence of the measurement accuracy of the sensors.

The block d.) Thus not only represents a state observer, but also contains further functions for signal processing. Especially here Of particular note at this point is the sensor adaptation, which is intended to reduce the influence of sensor inaccuracies. To perform a sensor adaptation or correction, information from other sensors and models is needed. Since this information is present in block d.), The sensor correction and adaptation also takes place there.

According to 8th The functions of the observer for the entire system are grouped into the following three levels. Model Layer, Observer Feedback Layer, and Sensor Adaptation and Correction Layer. In the following, the above three levels are described in more detail.

Regarding The functional principle of an observer is the interaction of forward-facing process models arranged in the "Model Layer" layer and observer feedback, which are located in the level "Observer Feedback Layer", of essential importance. The return ensures that the process states calculated by the models, like pressures, speeds, temperatures, dynamically with the match actual values. The return is freely parameterizable, in particular it can also be structured in this way be that feedback, d. H. Corrections, to certain Subsystems remain limited. That way that can Problem of the design of a "big" observer, which uses all the information on that much easier too solving problem of the design of smaller observers for individual Partial models are reduced. Put another way, you can do the repatriation so that, for example, the drive train of a motor vehicle for correcting the air path of the internal combustion engine used is used, since both are coupled via the speed, and vice versa. Alternatively, you can do the return also parameterize that the air path only based on the information of the air path and the powertrain only on the basis of the information the drive train is corrected, d. H. the information remains locally confined to the modules. In many cases is it possible to determine the state variables to reconstruct different quantities, d. H. the system remains for different sensor configurations observable. Falls, for example, during operation a sensor and this is detected, so anyway nor, using an alternative observer feedback, the state variables are observed. One before Measured size can be measured this way reconstructed size to be replaced. This process goes through in the level "Observer Feedback Layer" realizes the "compare and select" (CnS) functions. The block d.) Also performs functions over the Observing the state of the system. The plane "Sensor Adaptation and Correction Layer "contains functions for correction and adaptation of the sensors, as described later becomes.

The communication of the levels within the block d.) Is in 9 shown. 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 plane. The ControlBus contains the control signals generated by block h.). The OfbBus contains the correction from the observer return level. The model-level output is the ModelBus, which contains all the modeled (estimated) signals. The sensor correction plane input variables / signals 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, ie block a.). The ResidueBus contains the calculated residual signals from the return plane (CnS functions). The OfbBus contains the correction from the observer return level. The ModelBus contains all modeled (estimated) signals from the model level. The sensor correction plane evaluates the signals contained in said buses so that the output of the sensor correction plane are the corrected sensor signals contained in the SensorCBus. Input variables of the feedback plane 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 plane. The ReconfigBus contains reconfiguration information from the reconfigurator, ie block f.). The observer feedback plane evaluates the signals contained in said buses so that the output of the observer feedback plane is OfbBus, ResidueBus, and SystemBus, or the signals contained therein. The SystemBus contains the sensor sizes and model sizes selected in the Compare and Select (CnS) functions that describe the current state of the engine / vehicle.

In 9 not shown are those from the controller, so block h.), About the communication interface, so block c.), Sent signals. These are treated in exactly the same way as the ControllerBus, since these are nothing else than control signals that are not output via the actuator interface in block b.).

Within the block d.) The following functions are to be realized. The model level contains Process models of engine and powertrain. These process models are grouped into modules as follows for a model description of a combustion engine in connection with 8th being represented. The module "Air System Model" (AirSysMdl) contains a model of the intake-side air system of an internal combustion engine. This includes the charge change model known as charge detection. We model variables such as pressures, temperatures, filling (fresh air and possibly residual gas). Depending on the vehicle, this model must be adapted, ie configured. Variants here are, for example, a freisaugende or supercharged internal combustion engine with or without external exhaust gas recirculation.

The Module Fuel System Model (FuSysMdl) contains a model of the Fuel system of an internal combustion engine, consisting of Low and high pressure side. It includes u. a. the components tank, Fuel pump, activated charcoal filter (tank ventilation), High pressure pump, rail and injectors. To be modeled thereby Parameters such as pressures, temperatures, fuel mass flow from tank ventilation. Depending on the vehicle, the model must be system-specific be adjusted. Variants here are, for example, an internal combustion engine with intake manifold or direct injection or the type used High pressure fuel pump.

The Module "Combustion Model" (CmbMdl) contains a thermodynamic model that balances the energy in the combustion chamber. To be modeled are the mechanical energy or the Torque, the heat flow through the cylinder walls or the coupling to the cooling system, the energy flow into the exhaust system (possibly the individual species), the combustion chamber lambda, the center of gravity of the combustion. The selection of the to be modeled Sizes also depend on the operating method the underlying internal combustion engine, so whether it is for example, a gasoline, diesel or gasoline auto-ignition method is.

The Module Exhaust System Model (ExSysMdl) a model of the exhaust system of an internal combustion engine from Exhaust valve to the exhaust. It describes the dynamics of pressure and temperature as well as the exhaust lambda. The configuration of the model depends on whether it is an internal combustion engine with or without turbocharger or depending on the number and type of catalysts.

The Module "Powertrain Model" (PtMdl) contains a powertrain model that delivers quantities such as speeds, vehicle longitudinal speed, Longitudinal acceleration, torsion angle, transmittable Clutch torque, driving resistance or pitch angle. Depending on the vehicle, this model must be adapted. Variants are Here, whether it is, for example, a drive concept with a manually operated change gear, an automatic Gearbox or a parallel hybrid, so a combination of Internal combustion engine and electric machine, acts.

The Module "Thermal System Model" (ThSysMdl) a model of the cooling system. It describes the temperatures the different cooling circuits and is also to configure depending on the drive concept.

The Module "Electrical System Model" (ElSysMdl) contains a model of the electrical system of a drive concept. It For example, this could be a simple battery model or, in the case of a hybrid drive, a complex model the power electronics and electric drives.

In the observer return level / return level For each hardware component exists a module in which two functions are housed. These realize the calculation of the observer feedback (Ofb functions) and the calculation of the residuals including the selection the signals written to the system bus (CnS functions). The Observer feedback determined from the residuals a correction value. It uses the entire residual bus, d. H. in principle, all the residuals of all models for the calculation of the correction value are used.

The correction value calculated for a component model is used in conjunction with 9 described method of communication is fed into the model in question and there serves to correct the estimated state. In the CnS functions a signal selection is made. By way of example, this signal selection is in 10 illustrated, 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 is selected. The selection is made via a status variable read out of the reconfiguration bus here CR_stRec. In addition, the residual CR_pResi associated with the respective measurement signal CR_pMesC is calculated as a deviation between measured value CR_pMesC and model value CR_pMdl.

In the sensor correction and adaptation layer, functions are implemented which, for example, perform a sensor correction on the basis of a stationary, non-zero residual. An example of this could be the adaptation of a Drucksen sors, wherein by an adaptation algorithm, a print offset is determined, 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 is the scope of the block e.), So the diagnostic manager shown. The diagnostic manager is a central management body of the underlying to the respective drive concept device for control and regulation or the respective control unit. The block e.) Contains all modules and in their custody all functions that are necessary for the central organization and coordination of the system processes or for the central recording and mapping of the system status. Its tasks are the central recording, management 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 error memory), "Coordination Manager", "Symptom Manager", "Statistic Tools", "Production / End of Line / Garage" and "System Manager".

in the Diagnostic Manager will be all information about the operation and centralized the system state, analyzed and mapped. The evaluation of this information takes place centrally and will used for planning the further system sequences. In This is the context of the "Coordination Manager" module as coordinator the internal system processes are of central importance. For the fulfillment of legal requirements and in particular the requirements of the field of on-board Diagnostics (OBD) play the modules "Symptom Manager", "Diagnostic Manager" and "Statistic Tools" important role. For servicing demands from the areas of production, End of tape and workshop is a separate placeholder ("Production / End of Line / Garage "). The module "System Manager "serves as a container for all others, also cross-system functionalities that have or need to be related to the engine control unit.

The internal communication and the significant signal flow within the diagnostics manager are in 12 shown. As a central element in relation to all processes in the Diagnostics Manager, the Coordination Manager module is of crucial importance for system workflows. The planning of the system processes depends on the results of the diagnostics ("Diagnostic Manager") and the requirements from the blocks "Statistic Tools", "System Manager" and "Production / End of Line / Garage". The SysCoordBus and the xxxStatusBus serve 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 diagnostic result (pinpointing) is the task of the "Symptom Manager" module, which includes the evaluation (including preliminary debounce), the information from block a.), Ie the sensor interface (SensorStatusBus), and block b.), Ie the actuator Interface (ActuatorStatusBus, ie for "xxx" is here "Actuator"), and the block g.), So the diagnostic function (DiagnosisBus), takes over. He communicates his findings to the "Diagnostic Manager" module and via the DiagResultBus. The "Diagnostic Manager" module implements the error memory entries, their administration and transmission to block c.), Ie the communication interface via the (ComlnBus / ComOutBus). The module "Statistic-Tools" accesses results of the "Diagnostic Manager" as well as other system information from different buses. In the context of z. For example, the IUMPR also accesses the "Coordination Manager", where "IUMPR" stands for "In use monitor performance ratio" and refers to the running frequency of selected non-continuous diagnoses, a precise definition being "Title 13, California Code Regulations , Section 1968.2 ", as the relevant instrument for certification in California. External communication takes place via the buses ComlnBus and ComOutBus. In the modules "System Manager" and "Production / End of Line / Garage" functionalities can be called up and executed via the module "Coordination Manager" (eg short trips, actuator tests). The communication via the communication interface, ie block c.), Via the buses ComlnBus / ComOutBus enables the exchange of data with the periphery. Required system information is taken from the SystemBus. To support maintenance, the module "Production / End of Line / Garage" can use information from the DiagnosisBus, the "Symptom Manager" and the "Diagnostic Manager". Within the system, the requirements for the "Coordination Manager" are forwarded for coordination.

The Module "Diagnostic Manager" includes the acquisition and management of diagnostic results. This includes as well the realization of functionalities, such as debouncing and healing as part of the on-board diagnosis. additionally Here are mechanisms for dealing with FreezeFrames and the control for example, MIL (Malfunction Indicator Lamp, display of Errors in the OBD), EPCL (Electronic Power Control Lamp, EGAS monitoring).

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

The "symptom Manager "is responsible for processing the diagnostic results from the blocks a.), b.) and g.), ie the sensor interface, the actuator interface and the diagnostic function. To make sure Pinpointing is a corresponding cross-locking matrix to generate. To avoid false alarms (erroneous Display of an error) are pre-debounces (eg temporally or event-oriented) within the "Symptom Manager" module.

The Module "Statistics tools" includes u. a. features for the calculation of the IUMPR in the framework of the OBD. Optionally here also further statistical evaluation functions and customer-specific system analysis functions be deposited.

in the Framework of the module "Production / End of Line / Garage" Functionalities from the areas of production, end of tape and workshop reserved. As examples here are the introduction of short trips and actuator tests as well as the realization of adaptation channels and the implementation of the controller coding called.

in the Module "System Manager" will be functions, such as z. B. WIV (maintenance interval extension) and WFS (immobilizer) deposited.

Furthermore, the block h.), So the controller, shown in detail. The block h.), Ie the controller, generates from the block d.), Ie the observer / the signal processing, from the block f.), Ie the reconfigurator, from the block e.), Ie the diagnostic manager, from the block c.), ie the communication interface and the block g.), So the diagnostic function, provided signals controls the actuators, ie the controller contains all functions for controlling and regulating the engine and powertrain. 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, "powertrain coordination"), "ExCtl" (Exhaust System Control, "EffCoord" (Efficiency Coordination), "TqCtl" (Torque Control; Control), "AirCtl" (Air System Control), "CmbCtl" (Combustion Control), "FuCtl" (Fuel System Control, "ThCtl") (Thermal System Control) and "ActCtl" (Actuator Control). The principal signal flow within the block h.) Is in 13 shown. Four cascades can be identified from left to right, starting with the driver's interpretation of the "PtCtl" module, which is far away from the process, via torque control in the "TqCtl" module, the "AirSysCtl" process controller and the throttle position loop in the "ActCtl" module. Overall, the interaction of the modules can be described as follows. In the "PtCtl" module, powertrain management, a setpoint torque is calculated from the accelerator pedal position and other variables. The ExSysCtl module generates efficiency requirements for heating and cooling exhaust system components. The torque request serves as a setpoint for the functions of the "TqCtl" module, which is of central importance. It serves to encapsulate the internal combustion engine as a torque actuator and for this purpose contains an inverse torque model, which maps the torque setpoint and the coordinated efficiency requirements from "ExSysCtl" into corresponding setpoint values for process variables, such as filling and rail pressure, as well as other motorized setpoints. The module "AirSysCtl" converts filling and / or pressure setpoints into a corresponding wastegate control and a throttle setpoint angle. The module "CmbCti" contains, among other things, the ignition angle calculation and the mixture control and regulation. The module "FuSysCtl" controls and regulates above all 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. All manipulated variables, including any binary variables for enabling / disabling output stages, are combined in a signal bus, the ControlBus. An exception here are control signals that are to be sent via the CAN, z. B. to an electric motor. These are combined in a separate signal bus, the ComControlBus.

According to the representation of the fundamental signal flow within the block h.) According to 13 The main signal path runs horizontally from left to right. Each module within the block h.) Or each function can access the information from block d.), F.), G.) And block e.) In the structure according to the invention. The drive management contained in the module "PtCtl" within block h.) Also receives external setpoint requests (eg setpoint torque from ASR) via the communication interface, ie from block c.). Since an internal combustion engine represents a coupled process, the individual controller functions are not completely independent of each other. Like the dashed arrow drawn by module "CmbCtl" to the module "FuSysCtl", there is also a vertical sig Flow possible and required. In this special case, it is a connection of the fuel setpoint volume flow generated by the mixture control to the rail pressure regulator function in the sense of decoupling / feedforward control. The "PtCtl" module represents the drive management and includes the functions driver interpretation interpretation, driver assistance systems (cruise control, speed and speed limiter), torque limitation, acceleration interface, driveability filter acceleration control and regulation, torque interface, aggregate coordination (Hybridko ordinator and driving strategy), antilock, idle and Approach controller, speed interface. Essential output variables are the setpoint torque for the "TgCtl" module as well as actuating signals (eg setpoint torque or nominal gear) for external units that are connected via a bus, such as a bus. As the CAN, be sent. Based on an inverse torque model of the internal combustion engine, the module "TqCtl" converts the target torque and the desired efficiencies from "ExCtl" into corresponding setpoints, eg for charge, high pressure, air ratio, ignition angle efficiency, efficiency of internal and external exhaust gas recirculation, tumble efficiency. Furthermore, the decision on the combustion 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 heating, component protection (catalytic converters and turbine) and for smoke limitation. Output variables are target efficiencies / set torques for ignition and lambda and the requirement for idle speed increase. The "AirSysCtl" module includes functions for controlling and regulating charge and intake manifold pressure or filling. The module "FuSysCtl" includes functions for the control and regulation of low pressure fuel and high pressure fuel, for tank ventilation and for bleeding the fuel system. The module "CmbCtl" contains functions for ignition and injection valve control, for lambda control and lambda probe heating control as well as for knock control. The module "ActCtl" contains functions for the control and regulation of actuators, eg. B. the throttle position control loop. The module "ThSysCtl" contains functions for thermal management. This mainly includes the fan control.

Farther the block g.), ie the diagnostic function, is shown in detail. Rising legal and technical requirements for modern engine management systems do the constant testing and monitoring of the whole system including its sensors, actuators, Components and subsystems necessary. The minimum goal exists thereby in the fulfillment of the legal requirements in the context the OBD. In addition, the guided fault and troubleshooting in service and repair shop supported as well the realization of customer-specific wishes become. The goal is to disrupt and errors early to recognize, locate and identify consequential damage to be able to avoid engine and vehicle. The block g.) includes all system diagnostics that are not in the range of low-level diagnostics in block a.), b) or c.) or for E-gas monitoring in the block l.).

The structuring of the block g.) Takes place on the basis of the structure in the blocks d.) And h.), Ie the observer and the controller. The construction of block g.) Is in 14 shown.

To illustrate the legal requirements, another module level is introduced in block g.). The background to this is the higher resolution of the components with regard to exhaust gas-relevant components, which is anchored in the legislation. The additional module level is in 15 for the implementation of California's "Title 13, California Code Regulations, Section 1968.2".

The communication within the block g.) Runs in a vertical direction from top to bottom. The residuals (ResidueBus), model and sensor sizes (ModelBus or SensorBus) and shares (via SysCoordBus) are processed as input variables. Outputs of the block are, in addition to the diagnostic results themselves (DiagnosisBus), the status of individual diagnoses (DiagnosisStatusBus) and, if an active diagnosis is required, requests to the controller (DiagnosisControlBus). The structure is in 16 shown.

At the second (sub-) module level, the classification is based on the legislation. With reference to the in 15 In the case illustrated, the submodules to be realized are listed below. A list of the specific functions is not part of this disclosure, as this varies depending on the drive concept and sensor-actuator configuration. The aim of the second module level is to obtain an association between the diagnostic functions implemented and the legal provisions. The sub-module "Air System Monitoring" includes functions for implementing "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 Directive. California Code Regulations, Section 1968.2. The submodule "Fuel System Monitoring" includes functions for the implementation of "Fuel System Monitoring" and "Comprehensive Component Monitoring" based on the Title 13, California Code Regulations, Section 1968.2. The submodule "Combustion System Monitoring" includes functions for the realization of "Misfire Monitoring" and "Comprehensive Component Monitoring" based on the Title 13, California Code Regulations, Section 1968.2. The submodule "Exhaust System Monitoring" includes functions for the implementation of "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 Title 13, California Code Regulations, Section 1968.2. The submodule "Powertrain System Monitoring" includes functions for implementing "Air Conditioning System Component Monitoring" and "Comprehensive Component Monitoring" based on the Title 13, California Code Regulations, Section 1968.2. The submodule "Thermal System Monitoring" includes functions for implementing "Engine Cooling System Monitoring" and "Comprehensive Component Monitoring" based on the Title 13, California Code Regulations, Section 1968.2.

Furthermore, the block f.), So the reconfigurator, shown in detail. The reconfiguration (reorganization, reorganization) of the system is to be understood as a tool for the realization of fault-tolerant systems. The reconfiguration uses resources in the system to ensure operation even in the event of a fault. Further operation may only be partial, with reduced performance and / or for a limited time. The basis of a fault-tolerant system and thus for the implementation of a reconfiguration is a powerful diagnosis that enables precise pinpointing. Task of the block f.) Is to maintain the system operation and the system performance despite a fault occurring in the system, but at least to implement a "limp home" mode (avoiding lying down). The block f.) Is used to adapt and switch the system in case of error. Within the scope of this block, functions and fallback levels are to be stored which, in the sense of a fault-tolerant system, ensure safe operation of the motor beyond the time of a fault occurrence. The basic structure of the block f.) Is in 17 outlined. Analogous to block d.) And block h.), The structure of the components / modules takes place. In this way, the reconfiguration strategies belonging to a specific system component can be assigned to a module.

Of the Block f.) Comprises the reconfiguration strategies assigned to the individual modules, which differ in severity and extent. there It should be noted that block f.) is only active if a Error in the system has occurred, has been diagnosed and diagnosed by the manager in block e.) a corresponding reconfiguration request to the Block f.).

Depending on the particular reconfiguration strategy, block f.) May share block d.), H.) Or block d.) And block h.). The principle is in 18 shown schematically for the module "Air System". As an example of a simple implementation will be on 10 and the accompanying text. Depending on the system configuration and error situation, it is possible to switch to different substitute values for a sensor value here. The reconfiguration strategies are highly dependent on the system and the sensor-actuator configuration used. In addition, every reconfiguration measure has to be checked as an individual case in the event of a fault (safety, system stability). For these reasons, the strategies are stored as individual functions (software components) in the respective modules. The communication within the respective module runs in the horizontal direction from left to right. The diagnostic results (DiagResultBus) and the approvals (via SysCoordBus) are processed as input variables. Outputs of the block are the states of the individual reconfiguration functions (ReconfigStatusBus) and the respective reconfiguration measures (ReconfigBus). In other words, each strategy (function) generates from the input variables according to the stored functionality output variables which are distributed into the system or the modular structure according to the invention comprising the blocks a.) To h.). It is crucial that every reconfiguration strategy is to be considered isolated and that there are no cross-couplings or connections between the strategies.

QUOTES INCLUDE IN THE DESCRIPTION

This list The documents listed by the applicant have been automated generated and is solely for better information recorded by the reader. The list is not part of the German Patent or utility model application. The DPMA takes over no liability for any errors or omissions.

Cited patent literature

• DE 10044319 A1 [0002]

Claims (10)

Device for controlling and / or regulating a Drive system comprising a computer program code, wherein the Computer program code consisting of several blocks of modular structure is, wherein in each case at least one block for a.) one Sensor interface, b.) an actuator interface, c.) a communication interface, d.) an observer Signal processing, e.) a diagnostic manager, f.) one Rekonfigurator, g.) a diagnostic function, h.) a controller, intended is, where blocks a.) to h.) for exchanging data / information connected to each other, the blocks a.) to h.) Functions are assigned, depending on the Drive concept of the underlying drive system and / or the number or characteristics of the sensors or actuators used the blocks assigned to the blocks a.) to h.) are defined. Device according to claim 1, wherein the blocks a.) to h.) higher-level architectural or structural elements are as containers for modules and functions serve functions, elementary, definable components of Control and / or regulation of the drive system are a defined Fulfill the task and exactly specified interfaces have a module a set of thematically related Functions is. Device according to claim 1 to 2, wherein block a.) Is connected to sensors, wherein the signals of the sensors the functions associated with block a.) are processed so that as output variables of block a.) physical Sizes are available, with block a.) With block d.) is connected, the output quantities of the block a.) the block d.), whereby by the functions, the blocks d.) are assigned, a correction / adaptation of Signals from the sensors or a comparison of the signals of the sensors takes place with modeled signal values. Device according to claim 3, wherein the modular Structure next block a.) Also block b.), Where block b.) connected to the actuators to the respective power amplifiers block b.) is connected to block h.), wherein in the block b.) actuating signals are read in, which are formed in block h.), the functions associated with block b.) being a final processing the control signals, a driver for the power amp hardware form, form a driver for actuator hardware and Perform final stage diagnostics, where block b.) With block e.), the results of the final stage diagnoses carried out in block b.) managed by the diagnostic manager in block e.), where Block b.) Is connected to block d.), Wherein process variables or measured signals from block d.) to block b.) for correction / adaptation the control of the actuators are transmitted. Device according to claim 4, wherein the modular Structure in addition to block a.) And block b.) Also block d.) Includes, wherein Block d.) Functions for monitoring the current actual state assigned to be controlled and / or regulated drive system are using models based on control signals and environmental conditions measurable and immeasurable state variables of the Systems are estimated to be used for transmission of measurement signals block d.) is connected to block a.), being modeled measurable states are compared with measurement signals, wherein From this comparison emerge Residuen, with whose help a Observer feedback is realized, which corrects the modeled state variables, where Block d.) Further functions for the observation of System states are assigned, the observed states used to measure unmeasurable quantities in the control and / or regulation of the drive system to take into account or to provide substitute values in the event of a sensor failure, wherein Block d.) are further assigned functions that the block h.) And the block g.) associated with the information about provide the actual state of the system and the residuals, where block d.) linked to block b.), where modeled / observed or also transmits measured signals from the block d.) to the block b.) block d.) is connected to block g.), where measured / modeled Signals from block d.) To block g.) In order to to perform a diagnosis, block d.) with block e.), wherein release information / release requests the block e.), where block d.) with block f.), reconfiguration information from the block f.) to block d.) can be transmitted. Device according to claim 5, wherein the modular Structure next to block a.), Block b.) And block d.) Also block e.) includes, block e.) functions for central organization and Coordination of system processes and / or centralized recording and mapping the system state. Device according to claim 6, wherein the modular structure comprises, in addition to block a.), Block b.), Block d.), Block e.) Also block f.), Block f.) Being assigned functions which, in the event of an error, are reconfigured block d.) and / or Blo ckes h.). Device according to claim 7, wherein the modular Structure next to block a.), Block b.), Block d.), Block e.), Block f.) also block g.), where block f.) functions for active signal- and / or model-based diagnosis are assigned, wherein the necessary information about system states and residuals that serve as the basis for these diagnostic features serve, provided by block d.). Device according to claim 8, wherein the modular Structure next to block a.), Block b.), Block d.), Block e.), Block f.), block g.) also block h.), where block h.) functions for generating setpoints and control signals, for meeting strategic ones Decisions, to coordinate the functions and modules that associated with a particular hardware component are. Device according to claim 1 to 9, wherein the Drive system, an internal combustion engine or a coupling an internal combustion engine with a transmission for driving a vehicle or a coupling of an internal combustion engine with a generator system for generating electrical energy or the entire powertrain of a vehicle.