Abstract:
A system for running an internal combustion engine has at least two mode managers for activating and/or for requesting at least one combustion mode of the internal combustion engine. The system further has a combustion manager ( 9 ) wherein each of the output of the mode managers ( 1 - 7 ) are attached at least at one input of the combustion manager ( 9 ) for collecting and prioritizing all combustion mode requests active at the same time.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a U.S. National Stage Application of International Application No. PCT/EP2008/057472 filed Jun. 13, 2008, which designates the United States of America, and claims priority to EP Application No. 07011713.0 filed Jun. 14, 2007, the contents of which are hereby incorporated by reference in their entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    The present invention describes a system for running an internal combustion engine and provides a corresponding method having at least two mode managers for activating and/or for requesting at least one combustion mode of the internal combustion engine. 
       BACKGROUND 
       [0003]    To keep up to the strict upcoming requirements of the emission legislation the combustion engine needs to be continuously improved and at the same time must not compromise on the costs of the Engine Control Unit (ECU). The Engine Management System (EMS) is challenged with an increasing number of injections and combustion modes thereby increasing the cost and size of the ECU&#39;s memory and its computation time. A combustion mode can be described as a set of combustion parameters that can be controlled by the software. Typically for a DS EU 4 application the combustion parameters controlled by the software are: injected fuel mass, injection position, rail pressure, air mass flow, boot pressure and EGR rate. The EMS needs to manage more combustion parameters that requires to be tuned for every combustion mode. During the past years there was a dramatic increase in the number of engine management control modes that are applied in specific conditions. The best known example for this is the Diesel particle filter (DPF) strategy that activates the filter regeneration every few hundred kilometers. 
         [0004]    An other disadvantage in an EMS with an increasing number of combustion modes is the fast-growing ROM consumption due to the high number of calibration maps. This happens because the calibration engineers need to calibrate all the combustion parameters at each working point for each combustion mode in order to reach the relevant target such as consumption, noise, emissions, etc. 
         [0005]    Such a typical know EMS architecture is shown in  FIG. 1 . The increasing number of the combustion modes lead to the following problems. First of all only one combustion mode can be executed at a time. Therefore if two or more combustion modes are requested a decision needs to be taken. In order to solve conflict between combustion modes prioritization has been implemented at different levels in the software. Every time a new mode manager is introduced possibly all other mode managers such as DPF manager or RTE manager in  FIG. 1  need to be modified thus causing unclear and spread decision algorithm for mode prioritization. Additionally the transition between the combustion modes has to be handled in a torque neutral way. 
         [0006]    The simple approach of creating a calibration structure that allows the tuning of all combustion set-points and making a new copy of it for every new combustion mode is not feasible. The reason is that the required ROM resources for this would severely increase the ECU costs and in many cases it would force an upgrade to a better processor and additionally increasing costs. 
       SUMMARY 
       [0007]    According to various embodiments, a system for running an internal combustion engine can be provided which finds the balance between increasing requirements and the limited ECU resources. 
         [0008]    According to an embodiment, a system for running an internal combustion engine may have at least two mode managers for activating and/or for requesting at least one combustion mode of the internal combustion engine, and a combustion manager wherein each of the output of the mode managers are attached at least at one input of the combustion manager for collecting and prioritizing all combustion mode requests active at the same time. 
         [0009]    According to a further embodiment, the combustion manager may comprise a combustion mode transition manager for performing a transition from the current combustion mode to a target combustion mode. According to a further embodiment, the target combustion mode may be dependent on the result of the prioritization of the active combustion mode requests. According to a further embodiment, the system further may comprise means for activating the combustion mode transition manager in case the current and the target combustion modes are different. According to a further embodiment, the combustion manager may comprise an interrupt unit for interrupting the running combustion mode transition manager in case a new combustion mode request has a higher priority than the target combustion mode and the combustion mode request is requesting a jump. According to a further embodiment, the combustion mode jump request may be a zero torque request or a sudden high torque request. According to a further embodiment, the combustion mode transition manager may comprise means for performing the transition from the current to the target combustion mode over a nominal mode. According to a further embodiment, the system may use a single scalable calibration structure, a flexible linking between the calibration tables, the combustion set points and the combustion modes. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    The invention will now be described with reference to the accompanying and schematic drawing wherein: 
           [0011]      FIG. 1  illustrates an architecture overview of an engine management system with a decentralized structure according the prior art, 
           [0012]      FIG. 2  illustrates an architecture overview of an engine system management system with a centralized manager according to a preferred embodiment, 
           [0013]      FIG. 3  depicts three graph with identical time scales, wherein 
           [0014]      FIG. 3A  shows the requests of a mode manager over the time, 
           [0015]      FIG. 3B  shows the corresponding transition factor over the time, 
           [0016]      FIG. 3C  shows three modes and the reaction of the request from  FIG. 3A , 
           [0017]      FIG. 4  shows time dependency of five engine parameters, 
           [0018]      FIG. 5  shows a block diagram reading the transition factors in dependency of the transition, 
           [0019]      FIG. 6  illustrates calibration links between modes, sub-modes and calibration tables for one combustion set point, 
           [0020]      FIG. 7  shows two graph with different combustion mode wherein these two combustion modes only differ in one sub mode, 
           [0021]      FIG. 8A  illustrates a hysteresis curve over engine revolution, and 
           [0022]      FIG. 8B  illustrates a hysteresis curve over torque. 
       
    
    
     DETAILED DESCRIPTION 
       [0023]    It has been found that in order to handle the increasing software complexity, the solution is to create a central functionality that takes care of the prioritization and coordination. The combustion manager acts as a bridge between all the software strategies that need to take over the control of the injection system and the strategies that manage the combustion parameter calculation. 
         [0024]    It has been found that in order to handle the big memory requirement the solution is that the calibration tables are not assigned prior to a defined combustion mode and injection but give the flexibility to calibrate engineer to link the available tables or maps to a defined physical event such as first pilot injection in DPF regeneration mode. Thereby allowing the reuse of tables across injections or even across combustion modes. 
         [0025]      FIG. 2  schematically illustrates the architecture of the combustion related strategies in a diesel common rail EMS. The main inputs of the combustion management strategy are torque request (manager  1 ) from the driver and the combustion modes requested from external managers  2  through  7 . A mode manager is the software where the activation and request for each combustion modes are calculated. The main outputs of the combustion manager  9  are the individual combustion set points such as fuel mass setpoint  10 , injection phasing setpoint  11 , injection phasing setpoint  12 , air mass setpoint  13 , boost pressure setpoint  14 , EGR setpoint  15  that are inputs to the strategies such as injection realization  16 , fuel pressure realization  17  and air path realization controlling the actuators. 
         [0026]    As an example: the DPF manager  2  decides the event when particle filter regeneration is necessary and then sends a request to the combustion manager  9  to initiate the DPF regeneration mode. The combustion manager  9  in turn will command the actuators to perform the DPF regeneration. 
         [0027]    The nature and the number and of the external managers are dependent on the system components and the final Original Equipment Manufacturer (OEM). The general trend of the number of such external managers increases along with the emission legislation. 
         [0028]    Depending on the external manager strategy, one or more combustion modes are assigned. In general a combustion mode can be understood as a specific combustion target (e.g. start the engine, heat up the DPF filter, regenerate the DPF filter, etc.). The combustion manager  9  is introduced as a central coordination strategy in the EMS. The strategy takes care of mode request prioritization and controls the transitions between combustion modes. 
         [0029]    The combustion manager  9  acts as a bridge between the external managers  2  to  7  and the individual combustion set point strategies  10  to  15 . Thus giving the flexibility to develop a generic combustion set point strategy that is independent of the external environment of the combustion management strategy. 
         [0030]    The combustion manager  9  commands individual combustion set points for three independent systems within the engine:
       the injectors  16     the rail pressure system actuators  17     the air path actuators  18         
 
         [0034]    Each with a different reaction time. It is important to take such aspects into consideration for the coordination of the transition between combustion modes. For example a mode transition could trigger the transition of the set points for the slower system (air path actuators with the parameters MAP_SP: mass air pressure setpoint and MAF_SP: mass air flow setpoint) followed by the set point for the faster system (rail pressure system actuators with the parameter FUP_SP: fuel pressure setpoint) and finally the set points for the fastest system component (injectors with the parameters MF_SP: fuel mass setpoint and SOI_SP: start of injection set point).  FIG. 4  illustrates a simplified example of the possible implementation of a transition from combustion mode x to combustion mode y. The transition factor T 5  for mass air pressure MAP_SP and the transition factor T 4  mass air flow MAF_SP are identical and result in this example to T 4 , 5 =t 4 −t 1  wherein t 1  is the time when the transition starts and t 4  is the time when the transition ends. As can be seen from  FIG. 4  the transition factors T 4  and T 5  are the longest followed by transition factor T 3  of the fuel pressure FUP_SP defined as t 4 −t 2 . The shortest transition factor T 1  for mass fuel MF and transition factor T 2  for start of injection SOI are defined as t 4 −t 3 . With these transition factors it is possible to make a transition from one mode to another mode whereby each parameter reaches at the same the other combustion mode, here at time t 4 . 
         [0035]    It is possible to define transition times and/or delays for each combustion setpoint. Anyway it is not necessary to calibrate these times for each possible transition instead a limited set of times are defined and can be reuse as shown in  FIG. 5 . This figure shows in the left lower corner 5×5 array wherein the lines define the target mode and the columns define the current mode. According to the transition from one combustion mode to another combustion mode automatically the transition factor set is defined. Here in this example the engine is in the current mode  3  and a transition from this mode  3  to target mode  2  is requested. In the middle of this 5×5 array a black box  20  is marked. In this box  20  a pointer  23  is stored pointing to the transition factor set  22  (marked as black column) from a transition time table  21 . A transition factor set  22  is for example the transition times T 1  to T 5  as shown on the right side of  FIG. 5 . 
         [0036]      FIG. 3A  shows requested modes from one or several managers  1  to  7  over the time. In  FIG. 3B  the corresponding transition factors are depicted thereby only showing the transition factor of one parameter, for example T 4  of mass air flow. In  FIG. 3C  there different combustion modes CM 1  to CM 3  for one parameter are shown. At the beginning the engine runs in combustion mode CM 1 . At time t 5  a jump to combustion mode CM 2  is requested. The system is reacts instantly. The parameter is set to CM  2  as shown in  FIG. 3C . At time t 6  combustion mode CM 3  is requested in the transition time T a . Automatically the transition factor T a  in  FIG. 3B  is set (shown as a ramp). 
         [0037]    The normal case is shown between t 11  and t 14 . At time t 11  combustion mode CM  2  is requested in the transition time T C  (=t 13 −t 11 ). During this transition from CM 1  to CM 2  at time t 12  another combustion mode CM 3  is requested. As long as the transition from one mode to another mode is not terminated the new request is ignored. The transition from CM 2  to CM 3  only starts when the old transition has been terminated. This situation can be seen in time t 13  as the transition factor receives a new ramp. 
         [0038]    In certain situation the above rule has to be broken for example if a zero torque or a sudden high torque is requested. In this case a jump over rules any prioritization of the combustion modes. This is shown between t 8  and t 9 . At time t 8  a combustion mode CM 2  in the transition time T b  (=t 10 −t 8 ) is requested. At time t 9  a jump to combustion mode CM 1  is requested. Although the transition from CM 3  to CM 2  has not been regularly terminated at the time t 10 . The jump request has already been performed thereby overruling the transition from CM 3  to CM 2 . 
         [0039]    It is annotated that a request from a current mode (e.g. CM 1 ) to a target mode (e.g. CM 2 ) could always be passed over neutral nominal mode NM. The request would then be translated as CM 1 --&gt;NM--&gt;CM 2 . This by-pass over the nominal mode has the big advantage that the number of predefined transitions are reduced and the adaptation of a generic project to a OEM-project is much simpler and thereby reducing time and money during development. 
         [0040]    The known approach for calibration tables would be to define a calibration structure for each combustion set point in every combustion mode giving the advantage that the calibration structure could be adapted to the specific needs of the combustion mode. On the other side, wastage of the ECU resources would be seen, since the calibration tables can not be reused across the combustion modes. In addition, after tuning phase many calibration tables could stay unused. A deeper analysis shows that the basic dependencies like requested torque, engine speed and coolant temperature required for the calibration structures remain the same across combustion modes. This makes it possible to break the paradigm of a hard coded link between the calibration tables and a specific combustion set point in a specific combustion mode. By introducing a single scalable calibration structure, a flexible linking between the calibration tables, the combustion set points and the combustion modes solves the problem in a much more efficient way. 
         [0041]      FIG. 6  shows a schematic example of how the links between combustion modes, sub-modes and calibration tables could be established for a given combustion set point. Both layers of links can be freely chosen by the calibration team during tuning activities. 
         [0042]    As shown in  FIG. 6 , reuse of calibration tables is possible at two different levels:
       In the first level two or more combustion modes can share areas where the calibration of all combustion set points is identical by sharing the same sub-modes.  FIG. 7  illustrates an example where modes  0  and  1  share same calibration in most of the working area except for the region of high engine speed.   In the second level two or more combustion sub-modes can reuse the same calibration table. In Figure this is the case for sub-modes  1 ,  2  and  3  as they are all linked to table MAP[ 1 ].       
 
         [0045]    The combustion mode is converted into a combustion sub-mode. A combustion sub-mode can be understood as an injection profile (pattern of active injections). In order to avoid toggling a hysteresis is implemented as shown in  FIG. 8A  for engine revolution and in  FIG. 8B  for torque output. 
         [0046]    In order to improve the adaptability of the combustion management strategy to the needs of each project, the calibration tables are not defined as single elements but as arrays of several tables wherein number of elements as well as the dimensions of each array element can be configured. 
         [0047]    Defining the calibration tables for a given combustion set point as one single array would have the disadvantage that they all share the dimension of the biggest required table and thereby wasting CPU resources. 
         [0048]    In order to overcome this problem, several calibration table types are implemented for each combustion set point. For each table type, the dimensions can be configured separately. In case that one of the implemented table types is not required, the number of elements can be reduced to 1 and the element size to the minimum (2×2) so that the ROM consumption is negligible. 
         [0049]    The increasing number of combustion modes in diesel common rail projects increases the optimization effort for the calibration engineers. At least the following combustion set points need to be tuned at each working point in order to reach emissions, noise and fuel consumption targets:
       Injection activation profile   Fuel mass for each active injection   Position of each active injection (Injection phasing)   Rail pressure   Air mass flow or Exhaust Gas Recirculation (EGR) rate   Boost pressure       
 
         [0056]    Regardless of the calibration methods used to reach the optimization, the work of the calibration engineers is facilitated if the EMS shows the same software architecture for the calculation of each combustion set point. 
         [0057]    Due to the increasing requirements set to an EMS, an optimized combustion management strategy has become essential. A strategy having as main features a centralized combustion management and a flexible calibration structure is considered to be a suitable solution for systems fulfilling current and future emission standards. 
         [0058]    To summarize, the advantage of the centralized combustion management is that the strategy can be easily configured and adapted according to the needs either at the initial project phases or even at later stages of the project development. Indications from current implementations show that with a proper combustion strategy configuration and careful calibration strategy it is possible to reach the Euro 5 targets without significant increase in CPU resources consumption compared with Euro 4 systems.