Patent Application
20060173601
The present invention relates to a computer system and a method for controlling, especially for coordinating, the powertrain control of a motor vehicle.
In automotive technology, originally electronics was used only in the form of individual, electronified components, these components operating in an isolated manner, and independently of one another. Thereafter, these components were increasingly integrated into systems. Examples for this are electronic engine control systems, braking regulation systems or driver information systems. Currently, one may observe a trend towards the networking of all vehicle systems with one another, and increasingly also with the vehicle's surroundings.
Now, this recognizable growing together of the systems brings with it considerable technical and organizational challenges:
From DE 199 16 637 C1, a method is known for controlling the powertrain of a motor vehicle and a drive train control of a motor vehicle. The aim, in this context, even for motor vehicles having an automatic transmission, is to support the deceleration by the powertrain of the motor vehicle by the operation of the foot brake by the driver. A central control unit evaluates a braking torque command or a vehicle deceleration command of the driver, which, for example, is additionally a function of the operating parameters driver type, load state and road conditions (for instance, winter mode), which is manifested by operating the accelerator. Based on this ascertained braking torque, an engine drag torque setpoint value is determined. The transmission ratio of the automatic transmission is automatically determined as a function of the engine drag torque setpoint value, in the light of a downshifting characteristics map. Disadvantageously, all processes are controlled by a central control unit, so that adjusting of the central control unit to various vehicle types, or the introduction of new control components is not possible.
From DE 199 40 703 C1, a method and a device are known for engine control and transmission control in a motor vehicle having an internal combustion engine that is controlled by an engine control, and a stage automatic transmission that is controlled by a transmission control. In this context, the wheel drive torque (wheel torque), even in the case of a step automatic transmission, at constant accelerator setting, is changed constantly (continually) as plotted against the vehicle speed. The wheel torque has, as a function of the vehicle speed, a declining, hyperbola-like shape, in which, irrespective of the shifting processes, no discontinuity occurs in the wheel torque curve. From a wheel torque desired by the driver, the totality of torque coordinator, engine control and transmission control calculates a setpoint engine torque, and carries it out within the scope of physical boundaries. Outside of the shifting procedure of the step automatic transmission, this is achieved in that, at least as a function of the transmission ratio and the specified transmission drive torque, a torque demand acting on the charge and/or a torque demand acting on the ignition are calculated. With that, a certain engine torque is to be attained, which, while shifting in between the known transmission ratio, yields exactly the specified transmission drive torque. During the shifting process of the step automatic transmission, the implementation of the transmission drive torque takes place essentially via a friction element provided in the step automatic transmission. A certain torque is transmitted corresponding to the controlled variable selected for the friction element. That is why the controlled variable is set during the shifting process in particular in such a way that the desired transmission output torque is achieved according to a selectable transition function. What is disadvantageous here is that the wheel torque is a function exclusively of the accelerator swetting, and no other factors, such as driver type or wheel slip, are taken into consideration. The method and the device are not flexible, because their are integrated into an engine control and transmission control of a vehicle, and thus a transfer to other vehicle types and control unit configurations is not possible. Moreover, new control functions are also not able to be integrated.
From DE 198 38 333 A1 of the Applicant, a computer system is known having at least one processor and at least one memory for controlling a drive unit. It is the aim to state a control structure of the overall vehicle with the aid of which the drive train and especially the drive unit may be linked to externally lying components. Drive train and drive unit are merged into an overall vehicle concept in an engine management. The vehicle is regarded as an overall system, made up of functional units as a first component. The overall system, made up of functional units, is subdivided into various predefinable components, such as vehicle motion and drive coordinator. The drive unit, in this context, is specified as a component. The drive unit is controlled as a function of the specified components and/or the data exchanged at the interfaces between the components. Because of this composite system, individual elements or functional units can no longer be regarded separately, but merged into the overall concept. In a drive control or an engine control, for example, not only torque demands or power demands or rotary speed specifications of the vehicle motion, such as steering, brake or driving dynamics regulation have to be taken into consideration, but also power demands or torque demands and/or rotary speed data on all accessories and actuators. However, beyond that, there is also the possibility of carrying out a drive control adapted to the respective circumstances, by access to data and information of other functional units and systems, such as surroundings variables, driving state variables, vehicle variables and user variables. However, in this case it is disadvantageous that it is not possible to exchange individual functional units in module fashion, i.e. a flexible, module-type system construction is not present. Furthermore, inclusive statements on the concrete implementation of the specification of the aim are also not made.
From EP 0 883 510 B1 a powertrain control for a motor vehicle is known which includes a wheel torque calculating circuit, by which the setting of the accelerator is interpreted as a wheel torque or transmission output torque commanded by the driver, and is used for calculating setpoint values for the torque to be developed by the drive train, and which has a control circuit that is furnished with a fuzzy system, in which the desired wheel torque is evaluated together with operating parameters of the motor vehicle and with environmental parameters, by which, in the light of a central driving strategy selection circuit, the operating mode of the drive train is adjusted to predefined criteria, at any driving manner of the driver and driving situations of the motor vehicle, and which is connected to an engine performance actuator to which it emits an output signal, by which the setpoint wheel torque to be supplied by the wheels to the roadway is determined. A strategy is determined centrally for the engine control, the engine performance actuator and the drive control in such a way that the discharge of polluting agents is minimized. The central strategy may also have as a purpose a driving performance-oriented mode of the motor vehicle. All decentralized functional units are set in this strategy in such a way that a best possible acceleration and a quick response of the drive to the driver's command are available. Such a mode is necessary for a sporty manner of driving and for uphill driving The control takes place via a control circuit, the data exchange being carried out via a rapid serial bus communication, such as a CAN bus.
This has the disadvantage that, based on the overall configuration, there is only a very slight flexibility with respect to different vehicle configurations and control unit configurations and reusability of developed software components, because all the components are adapted to the central control circuit.
In motor vehicles, for different components in the powertrain, such as engine and transmission, interfaces are agreed upon for communications via which the demands are able to be transmitted, so that they may be carried out by the receiving component (in the motor vehicle field, a widespread technical interface for control unit networking is, for example, the CAN bus).
Besides the accelerator and the brake pedal there are many additional demand setters that can make demands on the powertrain. Typical examples for this are convenience systems, such as the vehicle speed controller, or safety systems, such as the ASR and ESP. In this context, a large portion of development and computing capacity is disadvantageously used to decide, corresponding to the current driving situation, at what point which system is actually permitted actively to specify or influence the operating point of the drive train.
It is known that, for controlling operating sequences of a vehicle, one may use embedded software solutions, building up on a real-time operating system as a standard operating system, e.g. ERCOS or OSEK or rather OSEKJVDX. In this context, application-specific functions, basic system functions, core functions as well as the corresponding driver software, that is, the specific base functions, are interwoven, on the one hand, with the different operating functions and suboperating functionalities on the other hand, which determine the actual operating behavior of the vehicle. Necessary or desired changes in functions, or the retrospective fitting in of functions permit creating very complex systems developments in the case of such interwoven software solutions, particularly of the interfaces.
From DE 100 44 319 A1 of the Applicant, the abstract idea is already known that one may achieve an optimization by the clear separation of operating functions and base functions and the introduction of a system layer or intermediate layer having an open interface function. In this context, one starts from an electronic system for a vehicle or from a system layer of the electronic system, the electronic system including first components for carrying out control tasks during operating sequences of the vehicle, and second components which coordinate cooperation of the first components for carrying out the control tasks. In this context, the components execute the control tasks by using operating functions and basic functions. Advantageously, the system is constructed in such a way that the basic functions and the operating functions or partial operating functionalities (designated as operating submodules or plug-ins) are clearly separated from one another, the basic functions being combined in a base layer. The system layer is then expediently superimposed on the base layer, which contains the basic functions. The system layer or intermediate layer, in this context, includes at least two of the second components that coordinate the cooperation of the control components. In this context, at least one open interface to the operating functions is provided, in or for the system layer, whereby the system layer connects the basic functions to any desired operating functions in such a way that the operating functions are modularly linked and/or used, or are able to be linked modularly to the electronic system. Thereby the operating functions or the operating sub-modules become able to be modularly linked to the electronic system, reusable, and exchangeable or changeable at any time. Because of the system layer, a defined interface is determined, so as to make possible, within the scope of the control unit software, a variant formation for any operating functions as well as broadenings or changes of the functionality, especially by operating sub-modules, so-called plug ins. Thereby, in one embodiment, a system that is already in mass production or in use or operation, may at any time be further refined, changed and/or broadened by the addition of new operating functions. With this, in a meaningful way, control tasks or specific performance features of an electronic system may be flexibly and individually designed, developed and implemented. Besides that, in addition, the monitoring functions with respect to the operating functions and/or the operating sub-modules may be linked to the system layer. Because of this modularization of the software functionalities and the monitoring functionalities, the possibility arises, for example, of linking software set up by third parties to the electronic system with little expenditure. This also permits constituting specific variants exclusively within the operating functions or the operating sub-modules, while the system layer may be designed independent of the application. What makes this disadvantageous is that only formal requirements are made, and concrete procedures, as regards content, are not given.
Starting from the described related art, the intention is to create a computer system and a method for control, especially for the coordinated control of the powertrain of motor vehicles, which have available definite procedures with respect to content.
The present invention proposes a computer system having the features of claims 1 and 25, as well as a method having the features of claims 8, 12 and 19. Advantageous refinements of the present invention are the subject matter of the dependent claims.
In this context, according to the present invention, in particular,
For the functionable putting into use of a module-type system construction, it is required that one state a software architecture in which clear functions are assigned to the individual elements or components. By the abstract concept of architecture, both the systematology of the structuring of a complex system composite and its practical putting into use are understood. For this reason, according to the present invention, a computer system is described having at least one processor and at least one memory for control, especially for powertrain control for a motor vehicle, which has available to it an appropriate software architecture. This is made up of the following elements or components: an operating system and specific services having a operating system and specific services as a basis for all other elements and applications, a basic functionality for adapting universal requirements, basic functions of a control unit, such as of the control of actuators of an internal combustion engine, being managed in the basic functionality, a “layer” for coordinating tasks for basic functionalities of the basic functionality, and for the linking of plug-ins and at least one plug-in for putting into use specific tasks or functions which go beyond the base functionality of the basic functionality and are coordinated by the layer.
In this context, advantageously, the plug-ins may be exchanged in module fashion in the computer system, whereby the computer system may be adapted in a flexible manner to different manufacturers' wishes and customer wishes, and functions are simple to implement. Therefore, the customer functions implemented in the plug-ins may be transferred in a simple and advantageous manner to various vehicle types or different engines, without having to change these. The adaptation to a changed vehicle configuration is undertaken by adaptations, for example, in the basic functionality (e.g. Diesel engine instead of gasoline engine).
Furthermore, new individual functions may be simply fit into the computer system by this module type of construction. Because of this, software sharing, for example, is also possible.
Besides, advantageously, in the software architecture open interfaces, which may be accessed from outside, and encapsulated interfaces, which are not open to the outside, are also integrated.
Possibilities for plug-ins for putting into use, for example, various characteristic properties of vehicles include, for example, an ACC request (adaptive cruise control request) for adapting the speed or the clearance of the vehicle, a driver's demand (comfort or sport) for rating and interpreting the accelerator, driveability for fixing a global optimization criterion, such as driving comfort or sport, as well as shift strategy (comfort or sport), which, from the setpoint value for the torque at the transmission output and the vehicle speed determine the setpoint value for the transmission ratio and the engine torque.
In the layer, for instance, the coordinators vehicle coordinator, vehicle motion coordinator and power train coordinator are integrated. Each coordinator should be able to communicate with the plug-ins, i.e. should be connected to the plug-ins via interfaces. Furthermore, the layer should be connected via interfaces to communication with the basic functionality, which contains base functions that act like sensors or actuators, the engine management, for example, acting as a torque setter, the transmission management converting a transmission ratio, the brake management setting a requested negative setpoint acceleration.
Requirements of various systems are centrally introduced in a uniform manner, based on system reference variables, e.g. the transmission output torque. Thus, the computer system according to the present invention permits a vehicle to adapt flexibly to various requirements, by the simple exchange or the addition of functions that are contained in plug-ins. Thereby, automobile manufacturers are able to introduce brand differentiation based on software, because vehicles having different properties are available based solely on different software components. Furthermore, costs may also be reduced to a substantial degree, because, to adjust to new functions, the entire computer system does not have to be exchanged, but the properties may be changed simply by the cost-effective exchange of individual plug-ins.
In order to achieve in a simple way the desired simple exchangeability of functions in the plug-ins, in the described computer system according to the present invention, it is necessary that the remaining components of the software architecture are able to access the plug-ins independently of the number and the manner of functioning of the plug-ins. Only in that way may the plug-ins be exchanged at will. A prioritization method, according to the present invention, of information sensors, such as plug-ins, for controlling, especially coordinating powertrain control for a motor vehicle, realizes this objective. The prioritization method may, for example, may be used in the just described computer system. In the plug-ins or requesters, a request command is included as a function of the current driving situation, there not having to be included, however, a request command for each particular driving situation in the corresponding plug-in or requester. The requesters or plug-ins are sorted according to the degree of their priority in rising or declining order, these priorities being determined as a function of global optimization criteria, such as an economic adjustment, a sport adjustment or a winter detection. In this appropriately sorted list having requesters or plug-ins, the individual requesters are processed sequentially beginning with the requesters having the highest priority, that is, a poll is made as to whether a request command is present in the requester or the plug-in. As soon as a requester includes a request command, the processing is discontinued, and the request command included in this requester is selected, preferably stored, and passed on. Each requester in the sorted lists may be uniquely designated by an identity (ID), preferably as a number, and its position in the list.
In an additional prioritization method, according to the present invention, of information sensors, such as plug-ins, in a list having requesters or plug-ins, all requesters are processed in any desired sequence, this list not being sorted by priorities and the processing being able to take place in this instance also sequentially, for example. Subsequently to this, the request command in the list of requesters is ascertained along with the maximal (minimal) request command or the average request command is ascertained. This maximal (minimal) request command is then stored and passed on.
In order to ascertain the maximal (minimal) request command, the scheme described below is generally used. The requesters or plug-ins included in the non-sorted list are polled in any desired sequence. The first polled request command, that originates with a plug-in that includes a request command, is first stored temporarily. Each additional polled request command is compared to the temporarily stored request command, to see whether it is greater (less) than the temporarily stored request command. If a polled request command is greater (less) than the temporarily stored request command, this polled request command is temporarily stored and the preceding request command is deleted, i.e. the value stored up to that point is overwritten by the currently polled value, and in the other case no storing taking place, i.e. the request command temporarily stored up to that point remains stored. After polling all requesters, the maximal (minimal) request command is temporarily stored and may be passed on.
In this connection, in one variant, with respect to certain requesters, such as requesters that control the engine and the brake, using one certain request command, for instance, a braking intervention, the minimal (maximal) request command, such as the minimal propulsion command, may be selected, and otherwise the maximal (minimal) request command.
In one further variant of the just described prioritization method, after maximal (minimal) selection it is also possible that individual requesters or plug-ins have the effect that certain other requesters are not taken into consideration in the ascertainment of the maximal (minimal) requeste command. For example, a requester accelerator may have the effect that all other requesters, which effect braking/deceleration, are not taken into consideration.
Each requester or a plug-in is clearly marked by an identity (ID), preferably a number, for processing. That means that the position in the list is not meaningful. Even in this prioritization method there are various lists for adapting to global optimization criteria, such as economic adjustment, sport adjustment or winter detection, it being only relevant here, however, which requesters are in the list.
The two prioritization methods just described may also be combined with each other, preferably the prioritization method first described being used first and, if this does not lead to a result, the second prioritization method is applied. The first prioritization method does not deliver a request command if, in the appropriate list, a request command is not included in any of the requesters or plug-ins.
For the coordinated powertrain control of a motor vehicle it is necessary to subdivide the complicated process of this control into individual method steps which can be carried out by an appropriate computer system, or rather, the software. A method according to the present invention for coordinating the powertrain control of a motor vehicle has essentially the following steps or phases:
For the characterization of the environmental influence in the first step, current environmental data are prepared and standardized, if necessary, such as vehicle variables (speed, transverse acceleration), powertrain condition (power transmission and trailing throttle/traction), driver type detection (sporting or economical, by derivation from his driving behavior) and driving situation detection (hill, curve, winter, city, expressway). In the 2nd step a global optimization criterion is determined. In the driver command interpretation as the 3rd method step, a specification is derived for the longitudinal motion of the vehicle, such as from the accelerator interpretation according to acceleration/deceleration and/or the specifications of a driving speed regulator or an ACC, a system reference variable transmission output torque being subdivided into a variable transmission output torque for the powertrain and a variable vehicle deceleration for the brake. For the determination of the optimal operating point in the 4th method step for a transmission output torque, a certain engine torque and a transmission ratio are ascertained. The approach to the optimal operating point in the 5th and last method step is carried out within a certain time, that is, the approach takes place not abruptly or as quickly as possible, but is adjusted to certain criteria, such as driveability, comfort, safety and engine protection. In these phases, preferably the individual tasks of the phases or steps are processed by coordinators in a layer of a computer system according to the present invention. The contents of the phases are transmitted or made available by the plug-ins via interfaces, the selection of the plug-ins preferably taking place according to one of the prioritization methods according to the present invention.
In order to create a computer system for the control, it is expedient to have available an object-oriented software system. An object-oriented software system is structured with the purpose in mind of assigning the software to individual parts or components of the object to be controlled or to state variables or even tasks. In a motor vehicle, these are, for instance, the vehicle, the vehicle motion, the engine, the transmission or the driver type, as well as the vehicle variable. The computer system according to the present invention, having at least one processor/memory and having an object oriented software system, is made up essentially of the following object-oriented components: Vehicle motion (VM), powertrain (PT), vehicle coordinator (VC), information providers, such as environmental data (ED), driving condition data (DD), vehicle data (VD) and user data (UD). In the information providers, current state variables are stored. These object-oriented components are connected to interfaces towards outside and inside (interface in and out) and a criteria coordinator (CC) for polling plug-ins for communication with interfaces. Component vehicle motion has additionally, for example, the components traction system and driving stability system (ESP), vehicle motion coordinator (VMC) and propulsion/brake (PrB). This component propulsion/brake additionally has, for instance, the components propulsion system (PrSy), brake system (BrSy) and a propulsion and brakes coordinator (PrBC) having a component acceleration request manager (AccRM). In response to a negative acceleration (deceleration), the acceleration request manager decides which proportion will be assumed by the engine and which part by the brakes. Component powertrain has, for example, the components powertrain coordinator (PTC), engine (Eng), transmission (Tra) and the information provider has powertrain state variables or powertrain data (PD). The criteria coordinator is able to communicate with an application programming interface (API). Thus, according to the present invention, an object-oriented software system is made available which is adapted optimally to a module-like system configuration.
In an additional refinement, the method according to the present invention, described above, is carried out using 5 phases and the computer system according to the present invention, having an object-oriented software system. It has the following steps:
In this method, the selection of the plug-ins is preferably made using the above-described prioritization method according to the present invention. Thus, this method permits executing the method, according to the present invention, for controlling a vehicle, with the aid of an object-oriented software system.
Parts of the present invention are also represented by the computer programs having program code means or computer program products having program code means, which are stored on a readable data carrier, in order to carry out one of the methods according to the present invention, provided the computer program is run on a computer or an appropriate calculating unit.
The present invention is described below as an example. The figures show:
The vision, on which the modular system construction is based, organizes the intelligent vehicle of the future into three essential elements, as in
Today's vehicles, as a rule, are characterized by grown electronic structures, having a multiplicity of isolated and autarchic individual functions and control units. Therefore, the development is mostly limited to optimization of the isolated individual functions and subsystems, but optimization of the overall system is taking shape with difficulty.
Therefore, to implement the vision of networkable systems in a vehicle, a coninual, consistent, modular and open system architecture becomes necessary. The aim of the system architecture is the seamless integration of all subsystems for the efficient representation of superordinated vehicle functions, which make it required to have several subsystems interact. Further aims are flexibility with respect to different vehicle configurations and control unit configurations, a simpler implementation of customer-specific functions, as well as great functional safety and reusability of developed software components.
By the abstract concept of “architecture”, both the systematology of the structuring of a complex system composite and its practical putting into use are understood. To describe the architecture, different views may be distinguished which are each shown by their own deascription (in the sense of differently abstract to concrete models), that are generated and made real in the individual stages of a development process, see
The basis of the system architecture of the module type of system construction is a hierarchically clearly structured functional architecture that is oriented to the vehicle topology, see
The functional architecture subdivides the vehicle into different “domains”: vehicle motion (powertrain), drive (vehicle motion), body and interior, electrical supply system, thermal supply system, etc. Inside each domain different subsystems are identified, which are made up of “functional components” that interact with one another via communications relationships. The concept component does not necessarily mean, in this context, the physical unit in the sense of a component part, but rather a functional unit which, as a subsystem, may be split up into further functional subcomponents.
Each of the subsystems itself coordinates its subcomponents, but the coordination of the subsystems is taken over by special functional components that are designated as coordinators. In the case of the communications relationships, the four basic types instruction, requests, feedbacks and polling are distinguished. A request is the wish to have a task executed, while an instruction is connected with the duty to execute it. While possibly several different functional components are able to place similar or even conflicting requests (for instance, different users a drive torque of an engine), placing the instruction takes place by exactly one instruction giver (e.g. a powertrain coordinator) to exactly one instruction taker (e.g. the internal combustion engine). If necessary, the instruction taker gives the instruction giver a feedback regarding the execution.
The functional architecture may be depicted graphically or even by UML models. Independently of the selected forms of description, the structuring rules on which this is based yield a consistent method, especially in the phase of systems analysis, for mastering the complexity, and permit the systematic definition of functional interfaces.
The next step in the development process is converting the functional architecture into a suitable software architecture. The software architecture describes the structures of the software of the system, and it is made up of software components which, within themselves, may be subdivided into additional software subcomponents. In general, the functional scope of a software component does not necessarily have to be equated to a functional component of the modular type of system construction. The functional structuring of components of the module type of system construction does, however, support and object-based software design.
In this partitioning, open and encapsulated interfaces may be distinguished. Encapsulated interfaces are not accessible from the outside, whereas open interfaces may be freely accessed. The modularity of this software architecture supports the exchangeability of subfunctionalities and thus makes possible software sharing.
For the implementation of the system composite, the partitioning of functions to concrete control units and the mapping of communications relationships on the network topology play a decisive role. Whereas in the traditional attempt at a grown system, in the first step, the partitioning of the control units and their networking were specified, and functional architecture and software architecture had to orient themselves to these actualities, the module type of system construction, in the present case, supports a systematic, simultaneous development process.
Because of the coordination of distributed systems on which it is based, the module type of system construction permits a flexible system implementation, both in decentralized distributed and in centrally concentrated control unit partitionings. Also, with respect to the use of specific bus systems and communications standards, the module type of system construction permits a great flexibility by encapsulation of the interfaces connected therewith. The specifically different topologies, depending on market segment and manufacturer, are therefore supported by the module type of system construction with a high degree of reusability of functional components and software components.
As the preceding comments have shown, clearly defined, standardized interfaces form a core element for managing the challenges of a composite system.
The system architecture supports the development of universal interfaces. Depending on the view, in this context, different implementation forms may be distinguished, see
An essential advantage is that the different interface forms may be transparently assigned and mutually converted. Thereby, at the time of developing a software function, considerable independence may be ensured of the software interfaces from the actual transport mechanism of the information (within a control unit or via a bus). By the encapsulation of specific subsystem properties, it may additionally be ensured that the interfaces are independent of the technical embodiment of the connected subsystems. An example is given by the torque interface to the internal combustion engine, which is universally suitable both for gasoline engines and Diesel engines.
This architecture supports the seamlessly functional integration of different electronic vehicle systems. In addition, the plug-in concept permits implementing software modules for the characteristic layout of the vehicle performance.
The layout permits the flexible configuration for different vehicle characters, designated below in exemplary fashion in two forms as “sporty” and “comfortable”. A switch in the passenger compartment enables the driver to switch over between these two vehicle characters. By contrast to the usual implementations of such vehicle characteristics, the difference is based not only on different parameter applications within the individual systems, but rather, on a superordinated plane, one draws upon software-“plug-in” functionalities to adapt the overall system behavior, which address via interfaces the individual systems that are unchanged in each case with respect to software and setting.
In order to represent the comfort character of a limousine of premium class, for example, the following requests were made as an example:
The vehicle should get an adaptive cruise control (ACC) system. This system makes possible an adaptation of the speed to a driving specification, as well as the distance from preceding vehicles, in that drive and brakes are activated electronically. ACC is an innovative equipment feature that emphasizes the premium character and increases travel comfort.
Electronic braking interventions for ACC and other longitudinal regulating systems (as, for instance, a driving speed regulator having brake intervention) should be possible via the brake control unit (BMU, brake management unit).
During throttle response, the vehicle should convey a soft feel, that is, jerky starting is to be avoided. Likewise, load reversals should be gentle, that is, the characteristic dynamics of the drive train should under no circumstances be perceptible to the driver. Gear shifting should be oriented rather to economical operation, i.e. the engine should primarily be operated at low rotary speeds.
In the sporty vehicle character, travel pleasure was optimized as the highest aim. In correspondence to the specified vehicle character, drive control and engine control should be designed as follows:
The engine should spontaneously respond to throttle, i.e. the accelerator interpretation should be “sharply” applied. Load changes should be able to take place rapidly, that is, the damping for the suppression of the drive train dynamics is secondary with respect to spontaneity. The engine operating point should be designed in favor of high rotary speed, so that the driver has as big as possible a power reserve available to him at all times.
For the demonstration of great flexibility, in this layout, one may do without incorporating the comfort feature “ACC”.
The uppermost layer is formed by six plug-ins, which contain the characteristic functions for implementing the requests to the two vehicle characters:
In
The layer is connected to the lower-lying software layer of the basic functionality via standard interfaces. From the point of view of the layer, these base functions behave like intelligent sensors or actuators. For example, component engine management functions as a torque setter, transmission management carries out the commanded transmission ratio, brake management sets the requested setpoint acceleration and ACC supplies the data from object recognition and ACC operating part.
As a result, a setpoint acceleration is ascertained which is distributed to the actuators drive (engine and transmission) or brake. In the case of braking, it is passed on to brake management via the interface. In the drive case, the acceleration is recalculated, with the aid of the traction force equation, to a setpoint torque at the transmission output, and then there follows the coordination with the request from driver's demand. As a rule, the request having the greater torque request prevails. In exceptional cases (depending on the) prioritization table) it may, however, also be meaningful that the decision is made in favor of the acceleration request of the ACC. For example, it proves to be comfortable when the brake deceleration is not ended abruptly if there is active braking of the ACC, and the driver is accelerating at the same time, i.e. when the driver is overriding. The resulting setpoint torque at the transmission output is subsequently passed on to the vehicle coordinator (see also
The vehicle coordinator passes the setpoint torque on to the powertrain coordinator (see also
The powertrain coordinator carries out the request for implementing a transmission output torque by the vehicle coordinator. Simmilarly as in coordinator vehicle motion, in the light of a prioritization method according to the present invention, the processing order of requests from the plug-ins, shift strategy comfort or sport, as well as driveability are determined. Depending on the prioritization table selected, only one of the two switching strategies is called up via the ID. Transmission management is instructed to carry out the setpoint value, while taking into consideration the minimum or maximum admissible gear from shift strategy. When there is a gear change, engine torque is transferred to base function engine, according to the specified lower and upper limit from dirveability.
All requests for the characters sport and comfort were able to be successfully carried out using altogether six plug-ins. Using the switch in the passenger compartment, one may switch over between the two modes during travel. The integration of the ACC system in the comfort version took place without change in the layer. This substantiates the power of the interfaces to the plug-ins, and permits the future integration of other applications, such as a situation-dependent speed limitation or cruise control having brake intervention as an alternative to ACC. The standardized interfaces of the layer to the base functions, such as engine and transmission, also makes possible decoupling the driving functions from the assemblies: they make possible the use of the same driving functions for different engine types (for Otto engines and Diesel engines) and different transmission types (e.g. for stage automatic transmissions and CVT.
Using the applicable prioritization method, dynamic changes between different driving behavior modes also become possible if this is requested, for instance, using a driver type recognition. In the present example, the change between the types sport and comfort of the plug-ins drivers demand and shift strategy demonstrates the flexibility of the prioritization method for the exchangeability of whole algorithms.
In contrast to the usual systems, which only permit a different characterization of the vehicle behavior by parameter change in isolated subsystems, the system architecture according to the present invention permits a far-reaching, flexible brand characterization of the overall vehicle by plug-ins along with simultaneous reuse of the software it is based on.
We are dealing with an overlapping, open system architecture for all control tasks and regulating tasks in the motor vehicle. It is independent of the vehicle type and of the control unit configuration. It is based on a clearly structured, hierarchical functional architecture and modular software having open, uniform interfaces in the participating control units. With that, the tasks may be distributed flexibly to individual hardware components of the electronic system. The ever more complex vehicle systems may be mastered more easily.
It was shown in an example that a flexible brand characterization is supported according to a top-down formulation. The characteristic functions for driveability are respectively concentrated in a plug-in. An applicable prioritization method makes possible the flexible coordination of the plug-ins. Thereby one succeeds in representing entirely different vehicle characters using a low software expenditure. Specified interfaces permit the modular integration of additional system elements. The plug-in concept makes it easy to share software, which gives the OEM (original equipment manufacturer, i.e. the automobile manufacturer) the possibility of characterizing his brand by independently developed software modules. A large measure of reusability of the software components, on which it is based, supports the requests according to cost effectiveness and software quality.
In motor vehicles, one normally has to choose between different propulsion requests, which come from either the driver or from auxiliary systems, such as FGR, ACC and ANB. The control unit software includes a program part that selects the most important requester.
During the implementation of the selecting method it is known which systems are able to make requests and how they are weighted with respect to one another. These requests are linked with one another in a fixed logic.
The methods used up to now have the disadvantage that it has to be known right from the beginning which system is able to make propulsion requests and what request combinations are able to exist. Because of that, the method has to be adjusted for each combination of systems.
The aim of the present invention is a method by the use of which one may meet the selection of the passed-on request or desire, especially for propulsion, independently of the number and the functioning manner of the requesting systems.
With the aid of a prioritization method according to the present invention, especially as a linear prioritization or as a maximum (minimum) selection, the selection of a passed-on requester or plug-in may be met independently of the number and the functional manner of the requesting systems. In the linear prioritization, a list or table of requests is processed sequentially, beginning with the requester having the highest priority, this list being sorted for linear prioritization, according to the degree of the priority of the requesters. Ending the polling of the list takes place as soon as a requester includes a request command. The requester is thereby selected. The remaining requesters that have not yet been polled are consequently not considered.
In the max (min) selection, all requesters are polled that are on the list for the max (min) selection. The requester having the maximum (minimum) request command is selected.
One may also combine the two methods with each other at will, for instance, by first carrying out a linear prioritization, and thereafter a min selection, in case the linear prioritization gives no result.
In the following, we describe, for example, the sequence of the selection of a propulsion command. The system includes, for instance, the following requesters:
The method used in the example, for ascertaining the most important propulsion command, is made up of 2 steps:
In the second step having max selection 2, it is polled in first operational step 7 whether there are still unprocessed IDs present. If yes, it is polled in next operational step 8 whether an ID has a request. If there is no request present, the procedure goes back the preceding operational step 7, and if yes, it is compared in next operational step 9 whether the just-polled requester is greater than an already stored requester. If no, the procedure jumps back to operational step 7, and if yes, the request is stored 5. If all IDs of the 2nd step have been polled, i.e. in operational step 7 there are no more unprocessed IDs present, the procedure jumps to operational step 6 for passing on the stored request. Thereby, for the IDs of the second step, the greatest request may be ascertained and passed on, in case the IDs of the first step include no request, since it was used in combination with the linear prioritization. As a further method, for example, an average value formation or a combination of these methods should be considered. For many real application cases this method will not be sufficient. In the following, two additional construction stages of the system are described:
In order to handle the IDs efficiently, they are managed in lists that are processed sequentially. Adaptation of the priorities to global optimization criteria (such as economical setup, sports setup or winter detection) can take place if the IDs are managed in 2-dimensional lists and, depending on the global optimization criterion, another row is used.
Now, if a requester is to be added, it should be entered into the right tables and it will thereby be automatically considered at the next selection.
It has to be excluded that an invalid request is routed to the engine or the brake. For this reason, it has to be ensured that the system is either preinitialized by having a valid value or it has to be guaranteed that, upon each selection, always at least one requester requests a value.
In the anonymous prioritization methods of information providers according to the present invention, the selection method does not know which quality the requester has. The only data it has are the ID and the position in the respective tables of the selection method. This leads to the fact that there are no inner dependencies of the requester and the selection system. Such a selection system is always required if one is to change the number of requesters without changing the code of the selection method. This method may be used, for instance, in an engine control, as shown by the above example. But there are still many additional products with regard to which this method has advantages.
The advantages of the prioritization method are, for example:
Below we shall describe an additional, concrete, procedure as regards contents for a modular system construction.
According to the present invention, a method for controlling, especially a method for coordinating powertrain control of motor vehicles is divided into 5 phases or steps:
In the 1st step of the coordinated powertrain control, current environmental data are prepared, if necessary typified, and made available. The following data groups are of interest, for example:
The 2nd step establishes what it is, based on which the entire following method is to be optimized. Criteria are conceivable, for instance, such as sporty driving manner, economical driving method or especially wear-preventive driving manner. The advantage of the global establishment lies in the subsequent uniform use in all decisive functions, from the acceleratot interpretation to engine torque selection and transmission ratio selection.
The subsequent driver command interpretation in the 3rd step has the task of interpreting the specifications of the driver and to derive therefrom a specification for the longitudinal motion of the vehicle. Besides the pure accelerator interpretation according to acceleration and deceleration, this includes also the specifications of a speed regulator or an ACC, which carry out the command of the driver for automatic travel at constant speed. A system reference variable transmission output torque, which includes acceleration and deceleration, is divided into a variable transmission output torque for the powertrain and a variable vehicle deceleration for the brake.
The driver command interpretation supplies as result a transmission output torque that is to be made available by the powertrain (the required auxiliary component power would still be added to this). For this, there now has to be determined an optimum operating point in the 4th step, to which an optimum of the selected optimizing criterion (see 2nd step) should be oriented. An operating point comes about in a conventional powertrain from the engine torque and the transmission ratio of the transmission, because the rotary engine speed, at a given vehicle speed, may be directly calculated from it. For future concepts, by installing further assemblies, there may perhaps come about additional degrees of freedom (e.g. an e-machine in 4-quadrant operation).
The last task of the coordinated powertrain control is the approach to optimum operating point in the 5th step. The current and the new optimum operating point may, under certain circumstances, lie relatively far “apart” (e.g. when the driver suddenly steps on the accelerator). In order to assure driveability, comfort, safety and assembly protection it is therefore frequently sensible not to permit any abrupt transition (as quickly as possible), but to approach the new operating point in damped fashion.
After the 5th step, the new operating point is established, and the appropriate specifications may be given to the components in the powertrain.
In phases 2 to 5, the actual design as to content of the task of the phase is assumed by plug-ins. For this, from each phase an appropriate interface is offered, via which (at least) one or more plug-ins are able to introduce suggestions of requests. These suggestions are first compared to one another by a phase-specific prioritization method according to the present invention, and the selected request command is routed subsequently by the phase, actually as specification to the next phase. Various methods are used for prioritization (simple rank sequence, maximal selection, average value formation and combinations of these methods).
For the development of the phases it is favorable to use a structure that is hierarchically oriented corresponding to the components and functions in the vehicle. For this, the modular system construction was used (see
In the following, the subdivision of the individual phases within the structure according to the present invention is shown, and the sequence of the entire powertrain control according to the present invention is explained once more in detail, especially with the aid of examples:
The system is thereby broadened by interface in and out, which is supposed to indicate that the individual software components for a functionable software also have to be connected to the real components and linked with additional control systems, and that for this, a special mechanism of software technology is utilized.
The interface criteria coordinator takes on a special status with regard to an undetermined number of plug-in components, Crit x In order to be able to simply broaden the system by any functions for coordinated powertrain control, these are transferred to plug-ins, and communicate with the system via a specific interface. In the light of the following figures, it is described how the functional subdivision between the system and the plug-ins and the appertaining communications proceeds.
In
The allocation of the characterization of environmental influences to the architecture takes place in the light of
The driver type recognition, driving situation recognition and vehicle variables are assigned to information suppliers ED, DD, Ud and VD in the uppermost plane, and are therefore visible to all the other components, and drive train state variables pd (powertrain data) are ascertained in the powertrain, and may also therefore be used directly only within the powertrain.
The 2nd step establishes based on what it is that the entire following method is to be optimized. Criteria are conceivable, for instance, such as sporty driving manner, economical driving method or especially a wear-preventive driving manner. The advantage of the global establishment lies in the subsequent uniform use in all decisive functions, from the acceleratot interpretation to engine torque selection and transmission ratio selection.
According to
The sequence shown in exemplary fashion on the left side of
In this example, there are, in the order of their importance, the three plug-ins “winter”, “sport” and “normal travel”. Except for normal travel, these have the property that they make a suggestion on the optimization criterion only (in other words, they are only “active”) if a certain situation is at hand, and if it is not at hand, they make no suggestion (that is, they are “inactive”). Normal travel is an exception in this respect, since it is always active, without a certain condition being at hand.
The sequence is described as follows: Before the colon, all the way on the left, there is the object that triggers an activity and calls up another object. After the colon, on the right, there is the method of the called-up object.
The vehicle coordinator first calls up the criteria coordinator to have it poll a suggestion for a vehicle optimization from the plug-in having the ID 1. The criteria coordinator knows the plug-in named ID 1, and fetches from it the current optimization suggestion. However, since the driving situation winter in the example is not active, it returns none, that is, no suggestion.
The calling up of the next plug-in takes place in the same way, but it returns the optimization suggestion “sport”, since the driver type is “sporty”.
Now, since a suggestion for an optimization criterion has been found, subsequent plug-ins having a lower priority do not have to be polled any more for a suggestion.
The proposed prioritization method at this point is as simple as possible, namely, a fixed sequence is established and the highest ranked active criterion that does not reply “none” is the winner. One advantage of this prioritization is that all criteria do not always have to be polled for, since the procedure may be stopped at the moment an active criterion has been found.
As an interface between the vehicle coordinator and the plug-in (uniformly for all plug-ins) a fixed quantity of conditions is agreed upon. The desired meaning, such as “sport” or “wear” has to be known to both sides, since the vehicle coordinator is supposed to introduce corresponding measures (call-up Crit_Get_VehOpt( )).
The driver command interpretation as the 3rd step, according to
The sequence of the driver command interpretation according to
The criteria coordinator offers still another special interface (application programming interface, API) for recalculating a vehicle acceleration into transmission output torque that is required at the current point in time, and vice versa, the criteria coordinator itself not fulfilling this task, but, for example, routing it on to the drive train, since the latter anyway includes the relatively costly recalculation for mastering its tasks. Thereby advantages accrue in the application of the plug-ins:
The exemplary sequence for driver command interpretation in
If the driver has activated it, the vehicle speed regulator tries to regulate a fixed speed by requesting a setpoint acceleration. The accelerator pedal interprets the gas pedal setting by the driver as an acceleration command. The standard gas pedal interprets the gas pedal setting by the driver in a speed-dependent manner as transmission output torque.
Via the criteria coordinator, the propulsion and brake coordinator first asks the plug-in having the ID 1 (vehicle speed regulator) for its propulsion command. It supplies a command for an acceleration of 1.1 m/sec2. The demand the PrBC is able to route outwards, however, is the transmission output torque and the braking deceleration. Therefore it instructs the acceleration request manager, AccRM, to carry out a standard subdivision of the demanded acceleration into propulsion and brakes. This gives a transmission output torque of 160 Nm and no deceleration.
Subsequently, the plug-in having ID 2 is called up. The accelerator pedal ascertains a desired acceleration of 1.2 m/s2 because of the driver specification at the accelerator. However, this plug-in takes care of the subdivision into propulsion and brakes by itself, via the API of the criteria coordinator, and gives a propulsion demand of 170 Nm and no deceleration back to the coordinator.
The third plug-in standard accelerator is not called up. In the previous step (establishing the optimization criteria), sport was established as the current optimization criterion. In the case of this optimization criterion, in the driver command interpretation, instead of the standard accelerator, in this example the acceleration pedal is called up, and the standard pedal is not needed.
In conclusion, the coordinator selects the plug-in having ID 2 as the winner, since its demand had the highest amount. In addition, it communicates to all the plug-ins that the plug-in having ID 2 has won with a demand of 170 Nm of transmission output torque and no deceleration. From this, the vehicle speed regulator is able to recognize that its suggestion has been overruled by another plug-in, and can act accordingly (e.g. holding onto the 1-share or deactivation).
The prioritization of the driver command interpretation is a broadening of the linear method: From the quantity of all plug-ins that are able to make a suggestion for driver command interpretation, only those are selected whose suggestion fits the current optimization criterion. Thus, for example, depending on the optimization, a normal accelerator pedal may be exchanged for a sporty accelerator pedal. Subsequently, a linear prioritization takes place of all those plug-ins for which a fixed ranking sequence can be established. This may be done, for instance, for a brake pedal, since during the operation of the brake, FGR and accelerator pedal have to be inactive (to be sure, only conditionally, see board test). If a plug-in becomes active in this phase, the method breaks off, corresponding to the linear prioritization.
If, however, no plug-in is active, all further plug-ins, that are not able to be ordered into a fixed ranking sequence, are called up. The prioritization then takes place, from the quantity of all suggestions, by a maximum selection.
Basically, with this procedure, only those criteria are drawn upon that fit the current optimization criterion; the actual prioritization takes place in a two-step method:
In a first (applicable) table, a sequence is established for the criteria according to which they are polled. The moment a command is recognized, the method breaks off. For some criteria this simple prioritization is sufficient (e.g. in the case of a request by a brake pedal, FGR and accelerator pedal, no further polling needs to be done.
In case no command can be ascertained in the first step, in a second step a maximum selection of the propulsion torque command is carried out of all requesters registered in a second (also applicable) table; provided there is at least one negative torque command, the smallest negative command is selected, and otherwise the largest positive torque command is selected.
As an interface, in contrast to the propulsion coordinator and the brake coordinator, two alternatives are available to the plug-ins. They may either request transmission output torque Mpropulsion and braking deceleration abrake, or a summation acceleration asum. If a summation acceleration is requested by a plug-in, the coordinator may itself decide how it wants to subdivide this to propulsion and brake (using the acceleration coordinator).
In order, on the one hand, to make easier the recognition of a non-present propulsion command (plug-in is inactive), (0 Nm is a definite propulsion command, and is therefore not suitable for characterizing of “no command”), and on the other hand, to indicate the interface alternative used, the plug-in additionally specifies the request type 0.1 or 2.
The driver command interpretation supplies as a result a transmission output torque that is to be made available by the powertrain (the required auxiliary component power would still be added to this). For this, there now has to be determined an optimum operating point as the 4th step according to
The determination of the optimal operating point according to
The sequence for determining the optimal operating point takes place again according to the scheme of the linear prioritization. As an example, three plug-ins are shown, having the tasks sport, hill and economical.
The powertrain coordinator calls up the criteria coordinator, to poll for a suggestion for an optimal operating point at a propulsion torque of 180 Nm from the plug-in having ID 1. The criteria coordinator knows the plug-in named ID 1, and fetches from it the optimal operating point. Since driving situation sport is not active, it returns none, that is, no suggestion. Calling up the next plug-in having ID 2 takes place in the same way, and this indicates an optimal operating point having an engine output torque of 170 Nm and a transmission ratio of 0.666.
For the prioritization only those criteria are drawn upon that fit the current optimization criterion (an applicable table with all “fitting” criteria for each optimization criterion). For the criteria, a sequence is established according to which they are polled (see
The first active citerion is used. At the interface, consequently, the following takes place:
Call-Up: Crit_Get_OpPointProp (transmission output torque)
Return: engine output torque, transmission ratio.
The plug-ins are called up, the setpoint transmission output torque being transferred to them as parameters, so that the plug-ins know, according to their task, which torque demand an optimal suggestion is being polled for.
The last task of the coordinated powertrain control is the approach to the optimum operating point as the 5th step, according to
The approach to the optimal operating point according to
The finally ascertained result is routed from the powertrain coordinator to the components engine and transmission for execution.
The sequence for approaching the optimal operating point is based again on the linear prioritization method. As an example, the plug-ins curve, winter and hill are shown.
The powertrain coordinator calls up the criteria coordinator to have it poll a suggestion for a gradient limitation of the plug-ins having ID 1.
The criteria coordinator knows the plug-in named ID 1, and fetches from it a gradient limitation. Since Crit 1 is not active (curve, prevents a change in the drive train condition in driving dynamic limit situations), it replies “none”, that is, no suggestion.
The call-up of the next plug-in having ID 2 takes place in the same manner, and replies “none”, that is, no suggestion, since Crit 2 (winter) is also not active.
For the prioritization only those criteria are drawn upon that fit the current optimization criterion of the operating point ascertainment (an applicable table or list having all “fitting” criteria for each operating point criterion).
For the criteria, a sequence is established according to which they are polled (see
(An additional possibility arises in that a max or min selection is carried out from all requests).
At the interface, the following takes place:
Call-Up: Crit_Get_OpPointGrad( )
Return: Gradient limitation, e.g. in the form of filter parameters, min and max values for engine torque adjustment and transmission ratio adjustment.
The prioritization method for approaching the optimal operating point differs from the linear prioritization method in that there does not have to be one plug-in that also actually makes a suggestion, all plug-ins may reply “none”, which is then interpreted as approaching “as rapidly as possible” the new operating point.
The interface for the specifications of the plug-ins may turn out to be quite multifarious. What comes to mind is gradient limitations, filter parameters or absolute limits for engine torque and transmission ratio.
Corresponding to the assigned tasks, individual plug-ins may use one, several or all interfaces. The following exemplary plug-ins sport, crawling and curve thus use different interfaces.
Finally, the advantages of the entire invention are recited once more in summary:
| Number | Date | Country | Kind |
|---|---|---|---|
| 102 34 635.6 | Jul 2002 | DE | national |
| 103 34 536.1 | Jul 2003 | DE | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/DE03/02541 | 7/29/2003 | WO | 12/30/2005 |
