Patent Application
20080119977
The present invention relates to a control unit and a computer program for controlling a drive assembly, especially of an internal combustion engine of a vehicle.
Control units and appertaining computer programs are known in principle in the related art.
Some functional units in software 100b for a control unit 100 for controlling a drive assembly are, for example:
Individual ones of these known functional units are shown in exemplary fashion in
Starting from this related art, it is an object of the present invention further to develop a known control unit and a computer program for controlling a drive assembly of a vehicle in such a way that individual parts of the control unit, and especially of its software, are able to be implemented independently of each other and to be replaced.
According to the present invention, for a known control unit described above, a modularization is provided in the form of at least three modules, in a first module, those functional units being combined which are used for influencing the drive assembly in response to a user command on a physical plane, in a second module, those functional units being combined which make possible an individual programming of the hardware of the control unit in such a way that the hardware is put in a position of communicating with the modules of the control unit and which coordinate in time the processing of functions of the functional units in the modules and in a third module, those functional units being combined which make possible an individual adjustment of the sensor/actuator configuration to the control unit in such a way that between the individual sensors or actuators of the configuration communication is possible with the remaining modules of the control unit; and between the modules, module interfaces being provided for a module-overlapping communication.
The drive assembly, in the meaning of the present invention, may represent alternatively an internal combustion engine and also, for instance, an electrical drive or a fuel cell drive.
The user in the sense of the present invention may, for instance, be the driver of the vehicle, the legislator, a vehicle supplier or a vehicle manufacturer.
Physical level, in the sense of the present invention, refers to an abstraction of hardware specifics. This means that, on the physical level, with reference to the interface of the sensor with its surroundings, only physical variables, such as the rotary speed of the drive assembly, are being considered, but not their implementation in hardware in the form of an electronic signal having a hardware-specific amplitude representing the rotary speed.
Advantage of the modularization is that the individual modules are easily replaceable and may be implemented independently of one another. In this context, the subdivision of the functional units into the individual modules was selected in such a way that it makes sense particularly from the point of view of the vehicle's manufacturer and from a physical point of view. Replacement of individual modules is especially simple particularly because, in the specified module interfaces between the individual modules, all the dependencies between the functional units in the various modules have been taken into consideration, and dependencies going beyond this may exist, to be sure, even at the level of the functional units, but no longer exist at the level of the modules, and therefore no longer have to be considered when replacing the modules.
Cost savings and time savings are particularly connected with the proposed modularization. When using another control unit hardware or another sensor/actuator configuration, one no longer has to replace or adjust the entire software of the control unit, but rather it is sufficient if only the respective module is replaced.
According to a first exemplary embodiment, it is advantageously proposed to subdivide the first module into a vehicle component and into a drive assembly component. According to a second exemplary embodiment, it is proposed to subdivide the second module into an infrastructure component and into a hardware capsule, as well as, optionally in addition, also into a communications component.
In summary, it should be observed, in connection with the above-named exemplary embodiments, that the subdivision of the individual modules into components, similarly as in the case of the modules, is used to improve the replaceability of the components.
Advantageously, between the components within a module, interfaces for a rapid data exchange are also provided. On the other hand, a communication between components in different modules takes place via the module interfaces. Each of the components is, on its part, again subdivided into any number of functional units. Interfaces are also provided on the level of these functional units, so that various functional units within one component are able to communicate with one another. A communication between functional units in different components takes place via the component interfaces, and a communication between functional units in different modules takes place via the module interfaces. What was said above for the module interfaces applies also for the interfaces between the functional units, namely, that in these interfaces all the required dependencies between the functional units or the components among one another have been taken into consideration, and in each case additional dependencies do not have to be considered. The result of this is a simple replaceability not only of modules, but also of components or functional units, which means, in particular, a simple and uncomplicated adjustment to customer requests or new technologies.
According to one advantageous development, the functional units, the components and/or the modules, as well as their respective interfaces, are developed at least partially as a computer program. The development as computer program permits a flexible conversion of change commands without a change in the hardware of the control unit having to be undertaken.
Furthermore, the above-named object is attained by a computer program for the described control program. The advantages of this computer program correspond to the advantages mentioned above with reference to the control program.
Further advantages result from the following description.
According to the present invention, it is proposed that the functional units in control unit 100 be grouped into four separate modules.
In a first module ASW, those functional units are combined which are used for influencing drive assembly 300 in response to a user command on a physical level.
In a second module CO, first of all, those functional units are combined which make possible an individual programming of the hardware of control unit 100 in such a way that the hardware is put in a position of communicating with the modules of control unit 100. In addition, second module CO includes those functional units which coordinate processing functions of the functional unit in the modules ASW, CO, DE, CD over time. In addition, second module CO may also have such functional units as make possible communication of module ASW and/or a third module DE with other control units.
In a third module DE those functional units are combined which make possible an individual adjustment of the sensor/actuator configuration used to control unit 100 in such a way that, between the individual sensors or actuators of the configuration a communication is possible with the remaining modules of control unit 100.
Finally, in a fourth model CD, those functional units are combined which make possible a direct activation of complex sensor/actuator configurations having complex interfaces to control unit 100 by the first module. These special sensor/actuator configurations are to be distinguished from the aforementioned, non-special sensor/actuator configurations. In contrast to non-specific configurations in which communication with the first module is only via the second and the third module, in the special configurations there takes place a communication with the first module, directly via the fourth module.
Between modules ASW, CO, DE, CD, respective module interfaces M1, M2, M3, M4, M5 and M6 are provided which, first of all, make possible communication of the modules among one another, but also the replacement of individual modules.
As against this, in drive assembly component EF, preferably, all those functional units are combined which are specific for the type of drive assembly 300 used. In this context, preferably functional units engine coordinator EF-1, engine torque structure EF-2, gas system EF-3 or injection system EF-4 are involved, as was described above with reference to
Similarly to the case of the first module, it is recommendable in the case of the second module, for example, with regard to another processor to be used in control unit 100, to subdivide the second module into an infrastructure component IS and into a hardware capsule component HWE. In infrastructure component IS, preferably all those functional units are combined which offer or represent basic services, which other functional units are able to access. In this context, preferably the functional units services libraries IS-1, sequence control IS-2, diagnosis manager IS-3 and monitoring concept IS-4 are involved, as was also described above. The services are made available in the infrastructure component at a central location, and therefore do not have to be present decentralized in multiple versions and unnecessarily take up storage space.
In hardware capsule component HWE, all those functional units are combined which make possible an individual programming of hardware 100a of control unit 100 in such a way that hardware 100a is put in a position to communicate with modules ASW, CO, DE or CD of control unit 100. Thus, if there is a replacement of the processor being used in the control unit by a processor of another type, it is only necessary to replace hardware capsule component HWE, and no longer the entire second module of the control unit.
Besides the infrastructure component named and the hardware capsule component, second module CO may, in addition, have a communications component COM, in which those functional units are combined which make possible communication with other control units.
Besides the aforesaid module interfaces M1 . . . M6 at module level, component interfaces at the level of the components are also provided within the individual modules. These component interfaces KO . . . K3 make possible a data exchange between at least individual ones of the components within a module. Thus, there is an interface KO in the first module between vehicle component VF and drive assembly component EF. Within a second module there is a component interface K1 between infrastructure component IS and communications component COM, a second interface K2 between infrastructure component IS and hardware capsule component HWE, and a third interface K3 between hardware capsule component HWE and communications component COM.
In
For functional units HWE-1 . . . N of HWE it is advantageous to subdivide these in each case into a processor level element and a hardware abstraction level element. This subdivision offers the advantage that, for a desired replacement of the processor, not the entire hardware capsule component HWE but only the processor level elements have to be replaced, then, however, for all functional units of hardware capsule component HWE. By analogy, in the case of a desired replacement of the peripheral hardware of the control unit, that is the hardware of the control unit except for the processor, it is also no longer necessary to replace the entire hardware capsule component HWE, but rather, a replacement of the hardware abstraction level elements is sufficient for all the functional units of the HWE.
One functional unit allocated to hardware capsule component HWE is the functional unit signal preparation HWE-1, which was described in the introduction. For functional unit signal preparation HWE-1, processor level element HWE-1-1 takes on the signal preparation insofar as it relates to the processor type used, and hardware abstraction level element HWE-1-2 takes on the signal preparation insofar as it relates to the peripheral hardware used in the control unit.
Furthermore, interfaces Ek are provided for communication of processor level elements HWE-1-1 and hardware abstraction level element HWE-1-2 with each other and/or with superordinated functional units HWE-1 in HWE.
One of the complex unit drivers is the functional unit described in the introduction, namely, assembly position management EPM. For the sake of a clear allocation, its unit driver element and its hardware driver element are given reference symbols CDEPM-GT and CDEPM-HW.
As may also be recognized from
Finally,
In
Drive assembly component EF then executes a conversion of the setpoint torque received into physical variables that are dependent on the type of the internal combustion engine. If a Diesel engine is involved, for example, as internal combustion engine 300, assembly component EF generates a first actuating variable signal S6 which represents the physical setpoint injection pressure that is required for setting the required setpoint torque, as well as a second actuating variable signal S10, which represents the required setpoint fuel quantity on a physical level that is required for setting the specified setpoint torque. Depending on whether the generated actuating variable is provided for a normal actuator or a special actuator having a complex interface, drive assembly component EF passes the actuating variable to third module DE or to fourth module CD. In the example described so far, first actuating variable S6 is provided for activating a pressure regulating valve 200b2, which is a normal actuator not having a complex interface. Therefore, drive assembly component EF emits first actuating variable S6 via interface M2 to third module DE. The third module converts the input physical actuating variable S6 (software signal) into a software signal which represents the physical setpoint pressure in the form of an electrical signal S7 that is nonspecific for control unit hardware 100a. This signal S7 is emitted via module interface M4 to second module CO, where it is converted by ist hardware capsule component HWE into a software signal which represents an electrical signal that is specific for control unit hardware 100a. In this conversion, what may be involved is, for example, a quantization adjusted to the requirements of control unit hardware. Signal S8 generated by hardware capsule component HWE and emitted is supplied to control unit hardware 100a, which converts this signal into a real electrical signal for activating pressure regulating valve 200b2 as actuator.
In the example described, in parallel with the processing of first actuating variable signal S6, there takes place the processing of second actuating variable S10 by fourth module CD, after it was transmitted there via module interface M3. The fourth module converts signal S10, which represents the setpoint fuel quantity required for implementing the required setpoint torque in physical form, into a software signal, which represents a specific signal for control unit hardware 100a. This being the case, fourth module CD simultaneously takes on the function of the third module and of the hardware capsule component for special actuators having a more complex interface, as represented by a fuel injector 200b1 for setting the fuel quantity. Described software signal S11 that is emitted by fourth module CD is then also supplied to control unit hardware 100a, so that it converts the received software signal into a real electrical signal S12 for activating fuel injector 200b 1 as actuator. The activation thus taking place of pressure regulating valve 200b2 and of fuel injector 200b1 have the effect together of a change in torque of internal combustion engine 300, with regard to the driver command represented by the changed setting of the accelerator, or rather with regard to the setpoint torque representing this driver command
If a Diesel engine were not involved in the case of internal combustion engine 300, but rather a gasoline engine, three actuating variable signals would be generated by drive assembly component EF. First actuating variable signal S6, which is emitted to third module DE, represents a setpoint value for the air mass to be set, and second actuating variable signal S10 emitted to the fourth module represents the setpoint fuel quantity required for implementing the setpoint torque. In addition, a third actuating variable signal S13, is also emitted by drive assembly component EF to fourth module CD, actuating variable signal S13 specifying the ignition point for the sparkplugs of the internal combustion engine.
First actuating variable signal S6 is used, after a conversion into signals S7, S8 and S9, for activating the throttle valve, second actuating variable signal S10 is used, after a conversion into signals S11 and S12, in turn, for activating the fuel injector and third actuating variable signal S13 is used, after a conversion into signals S14 and S15, for activating a spark plug 200b3. The broken lines, drawn in
The functional units, components or modules are preferably implemented as computer programs. It is then possible to store these computer programs, possibly together with additional computer programs for controlling the drive assemblies, on a computer-readable data carrier. In this context, a disk, a compact disk, a so-called flash memory or the like may be involved. The software stored on the data carrier may then be sold to the customer as a product. In addition, in the case of a software implementation, it is possible to transmit the computer program as a product to the customer and to sell it in that manner, again, possibly, together with additional computer programs, even without the aid of a data carrier but via an electronic communications network. The communications network may, for instance, be the Internet.
In one specific broadening of the specific embodiments described up to now, we now specifically emphasize the configuration and allocation of the input and output signals of the modules, especially DE and CO as well as their descriptions. In this context, an intermediate module or an intermediate layer SZS is introduced, which makes possible the allocation of the signals between the modules, especially CO and DE. This is shown in
In a selected representation, there takes place the configuration of modules, advantageously via an XML description of the configuration parameters which are translated by configuration generators into corresponding *.c and *.h data files. This document describes the configuration of the software package digital input/output (DIO) via XML-based text files. In these XML data files, among other things, the properties of the signal class DIO are defined. The description of the DIO properties is carried out at various working levels. On the one hand, the DIO signals are requested by the project-independent device encapsulation (DE) having the parameters direction, initializing value and applicability (DIO_SIGNAL_REQUEST), and on the other hand, these signals have to be projected onto the specific application, i.e. the signals have to be routed to the appropriate hardware (DIO_SIGNAL_ROUTING). Requested hardware pins are likewise be configured (DIO_SIGNAL_IMPLEMENT).
When describing digital input and output signals, a distinction is made between device encapsulation (DE), hardware abstraction layer (HAL=SZS) and hardware configuration (module CO). However, this device is also found between further layers or may be used the same way between the remaining modules. Optionally, for example between ASW and CO as KSS3, or ASW and DE as KSS4, or ASW and CD as KSS5, as well as between CD and DE as KSS2. In this context, as in the case of KSS, there is always included the output module as CO, in this instance, as hardware configuration, a target module as DE at KSS having a request module or a request layer AS, and an allocation layer or a routing module SZS. This basic structure is also transferable to the remaining configuration interfaces KSS2 through KSS5. Subsequently, we shall only correspondingly describe KSS, that is, CO and DE, the applicability thereby of the remaining interfaces KSS2-KSS5 are regarded as being similarly illustrated.
The relevant configuration parameters for the component driver of DE may be represented in the abstract and independent of a project. In the case of digital input signals and output signals, on this level, for example, the signal name, the direction and the initializing value are of interest. In this context, from the point of view of the component driver, it makes no difference (assuming that the boundary conditions are kept) on which hardware the component driver is later to run.
The configuration of HAL includes the routing of the signal name to the corresponding hardware. In this layer, a generic hardware pin name is assigned to the signal.
The hardware-specific configuration settings are undertaken at the lowest level. The configuration parameters of this level refer to the corresponding module or to the signal class, and should no longer be viewed as project-independent and hardware-independent. The assignment of the signals takes place via statement of the hardware module (e.g. ADC, GPIO or CY310, CY100, etc) along with the desired port or pin on this module. In the case of the ADC module, in addition, the threshold voltage has to be given that makes the decision of high or low.
The setting of register values takes place via the configuration of the port hardware layer (the layer). On this level, requests come together that overlap the modules. For example, for the parallel interface, there exist requests from various modules or signal classes (GPIO, GPTA, SSC, CAN, etc). For this reason, hardware settings are not able to take place in a module-specific manner in a signal class (see also configuration process).
Thus the DIO configuration takes place on different configuration levels:
The subdivision of the configuration into various levels is not limited just to the configuring of digital input and output signals or of the DIO module, but also in other modules (ADC, PWM) there takes place the configuration corresponding to the above classification, including possible deviations.
The names of the XML configuration data files are basically freely selectable. Within DE, certainly a plurality of packet-oriented configuration data files will be created. On the HAL level, the signal routing may be distributed either into a central XML data file or to various configuration data files. In this connection, it will be seen which subdivision is most suitable for structuring of the project-specific configuration. The same applies to the setting of the hardware or the register configurations.
At this level, a signal is requested, from DE, on the part of the packet.
Each packet may create one or more XML data files having any desired data file name, and may request or reserve input signals and output signals from the Core/Hwe/Dio module. For this, the packet syntax is copied from the XML description for DIO (Packet layer—DE) into this(these) XML data file(s) and customized.
In the above example it is determined that a signal named “E_A_BRK” in packet “IN” is being used, that it has a certain direction (here “IN” for input) and that it is applicable (applicable means that the signal routing takes place during running time in the light of a signal table, and consequently it is able to be changed during operation. If the signal data are created exclusively at compile time, then the signals may no longer be alternate-routed) or not (here “YES” for applicable). The configuration of various signals may be repeated any number of times in an XML data file.
The tags DIO_CALIBRATION and DIO_INIT are optional tags. These should only be specified if, from the DE layer, there exist beforehand requests on type of access or initialization. A command on configuration is what is involved with these tags. If deviating settings are undertaken on the HW level, the requests from the DE layer are overwritten and also logged in the report data file (see also dump from the data file tmp/include_tmp/dio_report.txt).
The project carries out the signal routing on this level. The software signal name is, so to speak, assigned to the hardware pin name. This hardware pin name comes about from the desired hardware resource that is configured in the hardware layer (see configuration of the hardware layer).
As an example from the XML description for DIO (project layer.HAL), it is determined that a signal having the name “E_A_BRK” in packet “DIO” having the description (DESC) “Break signal” is being used, and that it is to be assigned to a certain hardware pin name “GPIO_P8_P0_IN” (port “8”, pin “0”, direction “IN”), (“GPIO” stands for access to parallel interface). The configuration of various signals may be repeated any number of times in an XML data file.
The hardware properties of TC1775/TC1796 are separated from the functional settings and specified in a separate configuration layer (HW layer).
Each project is able to create one or more XML data file(s) having any name and allocate certain properties to modules as well as their ports and pins (output stages and pins). These modules have to be functionally in a position to read and emit digital signals. For this, the syntax has to be copied from the XML description for DIO (hardware layer) into this(these) XML data file(s) and customized.
In the above example it is determined that a module having the name “GPIO” in packet “DIO” having the description (DESC) “GPIO_P8_P0_IN” is being used (“GPIO” stands for parallel interface). The resource (port “8”, pin “0”) is requested by this module and assigned to application identifier “YES” as well as to the initializing value “HIGH” (provided this makes sense at this point for an input). The configuration of various signals may be repeated any number of times in an XML data file.
The hardware pin name is a purely generic name which is uniquely assigned to a hardware resource, and is made up according to the following pattern.
<module name>_P<port number>_P<pin number>_<direction>
e.g GPIO_P8_P0_IN.
The hardware pin name may be taken from the DIO report data file after a configuration run (see below, Generic Hardware Pin Name).
It becomes clear that the XML elements <DIO_CALIBRATION> and <DIO_INIT> occur in respectively two different layers. Both XML elements are optional, i.e. in case these are not explicitly given, one may assume the following default setting:
If these XML elements occur both in the DE layer (request for a signal), and in the configuration of the hardware layer, the settings in the hardware layer have a higher priority on the project level. In saying this, we assume that the project level is able to undertake specific settings and carry them out with respect to the DE layer. Possible overlappings are also logged and may be inspected after the configuration run.
After carrying out the configuration according to the request of a signal and the routing of a signal, the stored XML data files have to be entered into the respective makefiles under the element CONF, see Mapping 5: Makefile having entered XML configuration data file. Makefile having entered XML configuration data file.
The input of the configuration data is made via an XML browser (e.g. XMetal). The XML structure is preset in the light of a document type definition (DTD) for the configuration of the miniproject. The DTD for the configuration of the miniproject lies in edc_hwe_vob in the miniproject under \scripts\xml\medc17_conf.dtd.
This DTD is being successively upgraded corresponding to the configurable data made available, by the developers of the core packets (modules) The XML configuration data files have to be validated via these DTD.
On account of the subdivision into various configuration levels it is possible, without detailed knowledge about the configuration manner of other layers, to make settings on different levels.
In this context, only the configuration parameters have to be given which are actually relevant for the layer to be configured.
The corresponding layer model is illustrated in
In the light of the description of digital input and output signals, this process can be very easily explained. In the uppermost layer (DE) a signal request is made to signal class DIO. Besides the direction, the initializing value and the parameter applicability, it is the signal name via which the request from DE is linked to the routing in HAL. In HAL, the signal name may now be routed to the appropriate resource. The mapping with the settings in HWL takes place via the signal name or hardware pin name of the pin. In the hardware layer, besides the module name, the corresponding port or pin has to be given also. The properties for the PORT hardware, such as the register settings, are attended to separately via the PORT configuration. The configuration of the individual layers is distributed, as a rule, to various XML data files. The configuration generators have the task of checking the configured data and to validate them.
After the call of the “make” or “make xml2conf” command in the miniproject, a data file list for the opened configuration data files is generated in the light of the registered XML configuration data files. Based on this, the central XML parser for the configuration (formerly core_parse.pl) gathers all configuration data files and data. Following the parsing process, the individual configuration generators are started, and the corresponding *.c and *.h configuration data files are generated.
In addition, the configuration generators check the consistency of the data and validate the user data. After the successful conclusion of the “makerun”, the configured signals may be used in the control unit code.
| Number | Date | Country | Kind |
|---|---|---|---|
| 103-07-698.0 | Feb 2003 | DE | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP04/50165 | 2/19/2004 | WO | 00 | 1/14/2008 |
