EP1597641A1 - Appareil de commande et commande d'une unite d'entrainement d'un vehicule - Google Patents

Appareil de commande et commande d'une unite d'entrainement d'un vehicule

Info

Publication number
EP1597641A1
EP1597641A1 EP04712578A EP04712578A EP1597641A1 EP 1597641 A1 EP1597641 A1 EP 1597641A1 EP 04712578 A EP04712578 A EP 04712578A EP 04712578 A EP04712578 A EP 04712578A EP 1597641 A1 EP1597641 A1 EP 1597641A1
Authority
EP
European Patent Office
Prior art keywords
module
hardware
functional units
control device
signal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04712578A
Other languages
German (de)
English (en)
Inventor
Bjoern Beuter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP1597641A1 publication Critical patent/EP1597641A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/04—Program control other than numerical control, i.e. in sequence controllers or logic controllers
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02D—CONTROLLING COMBUSTION ENGINES
    • F02D41/00—Electrical control of supply of combustible mixture or its constituents
    • F02D41/24—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means
    • F02D41/26—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor
    • F02D41/266—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using computer, e.g. microprocessor the computer being backed-up or assisted by another circuit, e.g. analogue
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/04—Program control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Program control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0423—Input/output
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/25—Pc structure of the system
    • G05B2219/25314—Modular structure, modules
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/26—Pc applications
    • G05B2219/2637—Vehicle, car, auto, wheelchair

Definitions

  • FIG. 9 shows such a known control device, wherein the reference symbol 100a represents the hardware and the reference symbol 100b the software of the control device 100.
  • the hardware of the control device 100 comprises at least one processor 100a-1 and at least one memory element 100a-2.
  • the software 100b is usually stored in the memory element 100a-2.
  • software 100b usually comprises a large number of functional units VF-1, EF-3, IS-2, HWE-1, HWE-3 and VF-3, which communicate with one another at least occasionally for the purpose of controlling the drive unit 300.
  • the drive unit 300 is controlled directly with the aid of a sensor / actuator configuration 200 connected between the control unit 100 and the drive unit 300.
  • Known functional units in the software 100b for a control device 100 for controlling a drive unit are, for example: • Drive unit VF-1: It manages the sources of mechanical energy and provides a setpoint torque for the drive unit for propelling the vehicle and for supplying the auxiliary units, usually as specified by a vehicle coordinator function unit. • Functional unit vehicle coordinator VF-2: It makes decisions about the
  • Function unit vehicle movement VF-3 It compares a current movement of the
  • Vehicle with the driver's wishes in order to ensure optimal driving stability. This includes, for example, the evaluation of the driver's request according to actions on the accelerator and brake pedals as well as the coordination of this driver's request with specifications from safety systems such as the electronic stability program ESP or anti-slip control ASR.
  • safety systems such as the electronic stability program ESP or anti-slip control ASR.
  • Functional unit driving state variables VF-4 It manages the information about current driving states, for example stop & go, driving uphill et cetera, regardless of which functional unit determines these driving states.
  • the engine coordinator has the task of coordinating all operating states of the engine and providing information about the
  • Functional unit engine torque structure EF-2 This functional unit has the task of determining and coordinating the torque requirements of other functional units for the engine and of determining a resulting requirement for torque conversion.
  • Unit position management EPM This functional unit has the task of a
  • Functional unit service libraries IS-1 Its task is to provide general, very frequently used functions that are requested or used by different functional units. It offers a central provision of these
  • Functional unit sequence control IS-2 It coordinates the time processing of requests from different functional units.
  • Functional unit diagnostic manager IS-3 This functional unit takes over the preparation of an error signal, which for example represents a defect in the hardware 100a of the control unit 100. The preparation consists in particular in debouncing the error signal and storing it so that the error signal can be evaluated at a later time.
  • IS-4 monitoring concept functional unit This functional unit is used in particular to monitor the processor of the control unit.
  • Signal conditioning function unit HWE-1 It performs a cleanup of an analog sensor signal after it has been digitized with regard to unwanted signal modulations that may have arisen in the control unit.
  • Functional unit gas system EF-3 It has the central task of providing information about the air mass currently available for the drive unit 300 and, within the scope of its influence on the drive unit, to monitor or adjust a desired target air mass and / or the exhaust gas quality.
  • This gas system functional unit is used in particular in diesel engines or gasoline engines.
  • Control unit exemplified. However, they were not all developed and implemented in the software 100b at the same time, but have only gradually been added to the software of the control device 100 in the course of the progressive development. So far, when adding new functional units, care has only been taken to ensure that the new functional units were able to communicate with all other functional units, if necessary. In the course of time, a confusing agglomerate of interfaces between the individual functional units has emerged, which has made the replacement of known functional units by modified functional units or the further addition of new functional units increasingly difficult. The difficulties arose in particular because existing dependencies between individual functional units were very difficult to understand when the entire system or only parts of it were redesigned. Starting from this prior art, it is the object of the present invention to develop a known control device and a computer program for controlling a drive unit of a vehicle such that individual parts of the control device and in particular of its software can be implemented and exchanged independently of one another.
  • Functional units are summarized, which enable individual programming of the hardware of the control device in such a way that the hardware is enabled to communicate with the modules of the control device and which coordinate the processing of functions of the functional units in the modules and in a third time
  • Module those functional units are summarized, which allow an individual adaptation of the sensor / actuator configuration used to the control device in such a way that communication with the other modules of the control device is possible between the individual sensors or actuators of the configuration; and wherein module interfaces are provided for module-spanning communication between the modules.
  • the drive unit in the sense of the invention can also represent, for example, an electric drive or a fuel cell drive.
  • the user can be, for example, the driver of the vehicle, the legislator, a vehicle supplier or a vehicle manufacturer.
  • Physical level in the sense of the invention means an abstraction of hardware specifics. This means that on the physical level, based on the interface of the sensor to its surroundings, only physical variables such as the speed of the drive unit are considered, but not their hardware implementation in
  • the main advantage of the claimed modularization is that the individual modules are easily interchangeable and can be implemented independently of one another.
  • the division of the functional units among the individual modules was chosen in such a way that it is particularly useful from the point of view of vehicle manufacturers and from a physical point of view.
  • An exchange of individual modules is particularly easy because all the dependencies between the functional units in the various modules are taken into account in the defined module interfaces between the individual modules; Dependencies beyond this may still exist at the functional unit level, but no longer exist at the module level and therefore no longer need to be taken into account when the modules are replaced.
  • the proposed modularization is associated in particular with cost and time savings.
  • it is no longer necessary to replace or adapt the entire software of the control unit, but rather it is sufficient if only the corresponding module is replaced.
  • first module it is advantageously proposed to subdivide the first module into a vehicle component and a drive unit component.
  • second exemplary embodiment it is proposed to subdivide the second module into an infrastructure component and into a hardware capsule and optionally also into a communication component.
  • Subdivision of the individual modules into components similar to the modules serves to improve the interchangeability of the components.
  • interfaces for fast data exchange are also provided between the components within a module.
  • Modules in different modules via the module interfaces.
  • Each of the components is in turn divided into any number of functional units.
  • Interfaces are also provided at the level of these functional units, so that different functional units within a component can communicate with one another.
  • a Communication between functional units in different components takes place via the component interfaces and communication between functional units in different modules takes place via the module interfaces.
  • the statements made above for the module interfaces also apply to the interfaces between the functional units and between the components, namely that in these interfaces all necessary
  • the functional units, the components and / or the modules and their respective interfaces are at least partially designed as a computer program. Training as a computer program allows flexible implementation of change requests without having to change the hardware of the control unit.
  • Figure 1 shows a modular Chile invention for a control unit
  • FIG. 2 shows a subdivision of the modules into components according to the invention
  • FIG. 3 shows an assignment according to the invention of functional units to a vehicle component and a drive unit component
  • FIG. 4 shows the assignment of functional units to an infrastructure component and a hardware capsule component
  • FIG. 5 shows a functional unit for a device driver element
  • FIG. 6 illustrates interfaces between the modules
  • FIG. 7 shows an interface between two functional units in different components
  • FIG. 8 shows an example of a data flow between the modules
  • Figure 9 shows the structure of a control device according to the prior art
  • FIG. 10 the embedding of an interface architecture according to the invention in the modular architecture
  • FIG. 11 shows the layer representation of a selected interface.
  • FIG. 1 shows, with reference to FIG. 9, a modularization of functional units according to the invention in a control unit 100 for controlling a drive unit 300, in particular an internal combustion engine, of a vehicle.
  • a control unit 100 for controlling a drive unit 300 in particular an internal combustion engine, of a vehicle.
  • FIG. 9 only the structure of the content of the memory element 100a-2 is shown in FIG. 1;
  • the sensor / actuator configuration 200 and the drive assembly 300 are not the subject of the invention and are therefore not described further below.
  • control unit 100 it is proposed to group the functional units in control unit 100 into four separate modules.
  • Influence the drive unit 300 in response to a user request serve on a physical level.
  • the second module CO comprises those functional units that coordinate the processing of functions of the functional units in the modules ASW, CO, DE, CD.
  • the second module CO can also have functional units which enable the ASW module and / or a third module DE to communicate with other control units.
  • a third module DE those functional units are combined that enable the sensor Z actuator configuration used to be individually adapted to the control device 100 in such a way that communication with the other modules of the control device 100 is possible between the individual sensors or actuators of the configuration ,
  • a fourth module CD those functional units are combined which enable the first module to directly control complex sensor / Aklor configurations with complex interfaces to the control unit 100.
  • These special sensor / ctor configurations are to be distinguished from the previously mentioned non-special sensor ZAklor configurations.
  • communication with the first module takes place directly via the fourth module.
  • module interfaces Ml, M2, M3, M4, M5 and M6 are provided, which on the one hand enable communication of the modules with each other, but also the exchange of individual modules.
  • FIG. 2 shows an inventive grouping of components within the modules ⁇ SW, CO and CD described above.
  • the first module ⁇ SW essentially represents user- or user-oriented functions. With regard to planned applications in which different types of drive units by the
  • control unit If the control unit is to be controlled, it makes sense to subdivide this first module ⁇ SW into a vehicle component VF and a drive unit component EF.
  • the vehicle component preferably includes those functional units that are not specific for a specific type of drive unit 300. These are in particular the functional units drive VF-1, vehicle coordinator VF-2, vehicle movement VF-3 or driving state variables VF-4, as described in the introduction.
  • motor coordinator EF-1 preferably the functional units motor coordinator EF-1, molecular structure EF-2, gas system EF-3 or injection system EF-4, as described above with reference to FIG. 9.
  • the second module is recommended for the second module, for example with regard to another processor to be used in the control device 100
  • Diagnostic manager IS-3 and monitoring concept IS-4 as also described above.
  • the services are provided in a central location in the Ihf ⁇ astruklur component and therefore do not have to be duplicated in a decentralized manner and take up unnecessary storage space.
  • the hardware capsule component HWE summarizes all those functional units which enable individual programming of the hardware 100a of the control device 100 in such a way that the hardware 100a is enabled to use the modules ASW, CO, DE or CD of the control device 100 to communicate.
  • the processor used in the control unit is replaced by a processor of a different type, it is only necessary to replace the hardware capsule component HWE and no longer the entire second module of the control unit.
  • the second module CO can furthermore have a communication component COM, in which those functional units are combined which enable communication with other control units.
  • Component interfaces provided at the level of the components within the individual modules. These component interfaces K0 ... K3 enable data exchange between at least some of the components within a module.
  • An interface K0 in the first module is between the vehicle component VF and the drive unit component EF. There is one within the second module
  • Component interface C1 between the infrastructure component IS and the communication component COM Component interface C1 between the infrastructure component IS and the communication component COM, a second interface K2 between the infrastructure component IS and the hardware capsule component HWE and a third interface K3 between the hardware capsule component HWE and the communication component COM.
  • FIG. 3 shows the already mentioned assignment of functional units to the vehicle component VF and to the drive unit component and the interface KO between the two components.
  • FIG. 4 shows the already described assignment of functional units to the infrastructure component IS and the hardware capsule component HWE within the second module.
  • the statements already made with reference to FIG. 3 regarding the interfaces between the functional units and the components apply here correspondingly.
  • these interfaces can also be designed such that there is a direct connection to each functional unit within a component. For communication between, for example, the functional unit service libraries IS-1 and the functional unit diagnostic manager IS-3, it would then not be necessary to communicate via the functional unit sequence control IS-2, but a direct connection would be available.
  • a functional unit assigned to the hardware capsule component HWE is the functional unit signal conditioning HWE-1, which was described in the introduction.
  • processor level element HWE-1-1 takes over signal processing insofar as it relates to the processor type used and hardware abstraction level element HWE-1-2 takes over signal processing insofar as it relates to the peripheral hardware used in the control unit.
  • Interfaces Ek are also provided for communication of the processor level elements HWE-1-1 and the hardware abstraction level elements HWE-1-2 with each other and Z or with them higher-level functional units HWE-1 in the HWE.
  • Each of these complex device drivers is in turn advantageously divided into a device driver element CD-GT and a hardware driver element CD-HW.
  • the elements CD-GT are via the interface M3 to the first
  • the device driver elements CD-GT receive such a different software signal from a hardware driver element CD-HW, they convert it * into a software signal that only represents a physical quantity, but is no longer specific to a sensor from which it was originally created.
  • the hardware driver elements CD-HW are used to directly connect the special sensor
  • ZAktor configuration 200 to the control unit hardware used, in particular to the processor 100a-l used.
  • One of the complex device drivers is the ssenggregate- Position Management EPM functional unit described in the introduction. Your device driver element and your hardware driver element are given the reference symbols CD £ PM -GT and CD EPM - HW for the purpose of clear assignment.
  • FIG. 6 exemplifies the module interfaces M2 and M4.
  • the arrows represent the dependencies between the modules shown or their components, which are realized by the interfaces.
  • the statement means that a module is dependent on a further module or a component is dependent on a further component, that this module accesses the further module or this component on the further component or the further module or the further component has data for processing in Order there.
  • the arrows representing the dependencies do not necessarily represent the corresponding data flow directions; these are explained below by way of example with reference to FIG. 8. From Figure 6 is too recognize that there is a mutual dependency between the third module DE and the first module ⁇ SW.
  • the dependency of the first module ASW on the third module DE represented by the arrow, which is oriented from the second module to the first module, results from the fact that the first module is dependent on the third module DE, for example, a Sensor signal and Z or an assigned one
  • Quality signal which represents information about the quality of the sensor signal, for the first module ASW.
  • the fourth module interface M4 realizes one-sided dependencies of the infrastructure component and the hardware capsule components with respect to the third module DE and a mutual dependency between the communication component COM with the third module DE. All three components mentioned are assigned to the second module CO.
  • the one-sided dependency of the infrastructure component and the hardware capsule component means that the third module DE accesses these components in order to have data processed there. analog
  • Figure 7 shows an example of cross-component communication between two
  • Functional units in different components of the same module. 7 shows a communication between the functional unit signal conditioning HWE-1 within the hardware capsule component HWE and the functional unit diagnostic manager IS-3 within the infrastructure component IS.
  • the signal processing functional unit depends on the diagnostic manager functional unit. This can lead to
  • the transmitted signal represents, for example, a defect in the hardware 100a assigned to the control device 100.
  • the functional unit signal processing HWE-1 then instructs the functional unit diagnostic manager to transmit the signal
  • the diagnostic manager functional unit then also has the task of storing this signal so that it is closed a later point in time, for example in a motor vehicle workshop, can be read out for the purpose of fault diagnosis.
  • FIG. 8 finally illustrates the interaction of the individual modules within the control unit software 100b on the basis of an exemplary course of signals.
  • Waveform analysis is an alternative way of describing the functions of individual interfaces, in particular between the modules, compared to the dependency analysis already mentioned above.
  • the two approaches are by no means contradictory to each other, but merely describe the functions of an interface in different ways.
  • FIG. 8 shows the signal curve that results when the driver of a vehicle in which the internal combustion engine 300 with the control device 100 is installed operates the accelerator pedal.
  • the accelerator pedal or a position detector attached to it is represented in FIG. 8 by the reference symbol 200a as a sensor of the sensor / actuator configuration 200.
  • a signal SI which represents the changed position of the accelerator pedal, is initially input by the accelerator pedal into the hardware 100a of the control unit 100.
  • the real electrical sensor signal is converted into a .software signal, which is initially still control unit-specific.
  • This software signal S2 then leaves the control unit hardware 100a and is fed into the second module CO, more precisely into its hardware capsule component HWE.
  • the software signal undergoes processing in such a way that the influences of the control device hardware 100a it still contains are removed from it.
  • a cleaned software signal is then present at the output of the hardware capsule component HWE, which in particular no longer contains any processor specifics. However, it still represents the characteristics of the original electrical signal, namely the changed accelerator pedal position, for example in the form of an amplitude of 3 V.
  • This cleaned signal S3 is then fed to the third module DE via the module interface M4.
  • the cleaned sensor signal S3 is processed in such a way that it is converted on a physical level in relation to the interface of the sensor to its surroundings.
  • the physical signal S4 at the output of the third module DE represents the changed position of the accelerator pedal represented by the signal S3 at the input of the third module in the form of the 3 V amplitude as an actual variable, for example in the form of 75% of the possible Represents the angle of rotation of the accelerator pedal.
  • the physical signal S4 is part of the interface M2 between the first module ⁇ SW and the third module DE. It leads from the third module directly into the first module ASW, more precisely into its vehicle component VF.
  • the vehicle component VF interprets the physical input signal S4 as a torque request for the internal combustion engine 300.
  • this torque request from the third module with any other torque requests that may be made to the internal combustion engine by other modules, components or functional units in order to ultimately produce a resulting target torque for the internal combustion engine in the form of the signal S5 via the component interface K0 to the drive unit component EF.
  • the drive unit component EF then converts the received target torque into physical variables that are dependent on the type of internal combustion engine. If the internal combustion engine 300 is, for example, a diesel engine, the unit component EF generates a first manipulated variable signal S6, which represents the physical target injection pressure required to set the required one
  • a second manipulated variable signal S10 which represents the setpoint fuel quantity required for setting the specified setpoint torque on a physical level.
  • the drive unit component EF transmits the manipulated variable to the third module DE or to the fourth
  • the first manipulated variable S6 is provided to control a pressure control valve 200b2, which is a normal actuator without a complex interface. Therefore, the drive unit component EF outputs the first manipulated variable signal S6 to the third module DE via the interface M2.
  • the third module converts the entered physical manipulated variable S6 (software signal) into
  • Conversion can be, for example, a quantization adapted to the requirements of the control unit hardware.
  • the signal S8 generated and output by the hardware capsule component HWE is supplied to the control unit hardware 100a, which converts this signal into a real electrical signal for actuating the pressure control valve 200b2 as an actuator
  • the second manipulated variable signal S10 is processed by the fourth module CD after the first variable variable signal S6 has been processed, after it has been transmitted there via the module interface M3.
  • the fourth module converts the signal S10, which represents the target fuel quantity required to implement the requested target torque in physical form, into a software signal which represents a signal specific to the control unit hardware 100a.
  • the fourth module CD takes over the function of the third module and the
  • Hardware capsule component for special actuators with a more complex interface such as an injection valve 200bl for setting the fuel quantity.
  • the described software signal SI 1 which is output by the fourth module CD, is then likewise supplied to the control unit hardware 100a so that it converts the received software signal into a real electrical signal S 12 for actuating the injection valve 200bl as an actuator. That was done
  • the drive unit component EF would generate three manipulated variable signals.
  • a third manipulated variable signal S6 which is output to the third module DE, represents a setpoint for the air mass to be set and the second set variable signal S10 output to the fourth module represents the setpoint force quantity required to implement the setpoint torque.
  • Command value signal S13 also output by the drive unit component EF to the fourth module CD, the command value signal S13 defining the ignition timing for the spark plugs of the internal combustion engine.
  • the first manipulated variable signal " S6 is used for conversion after being converted into the signals S7, S8 and S9
  • the second manipulated variable signal S10 after conversion into signals SI 1 and S12, in turn serves to control the injection valve
  • the third manipulated variable signal S13 after conversion into signals S14 and S15, is used to actuate a spark plug 200b3.
  • the one in Figure 8 within the modules or components drawn dashed lines only illustrate the assignments of input signal to output signal. They expressly do not rule out processing of the input signals within the modules or components.
  • the functional units, components or modules are preferably as
  • Computer programs implemented It is then possible to store these computer programs, possibly together with other computer programs for controlling the drive units, on a computer-readable data carrier.
  • a computer-readable data carrier This can be a floppy disk, a compact disc, a so-called flash memory or the like.
  • the software stored on the data carrier can then be sent to a product
  • the communication network can be, for example, the Internet.
  • a requirement module or a requirement layer AS is assigned to the module DE.
  • This SZS or the entire KSS now enables a general and flexible signal assignment, so that the module CO and the module DE can be designed independently of their interchanged input and output signals or their specific arrangement, since the correct signal assignment is in one Intermediate shift, the module SZS takes place.
  • the configuration of modules is advantageously carried out via an XML description of the configuration parameters, which are translated into corresponding * .c and * .h files by configuration generators.
  • DIO Signal class DIO defined. The description of the DIO properties is carried out at various levels.
  • DIO signals are requested by the project-independent device encapsulation (DE) with the parameters direction, initialization value and applicability (DI ⁇ _SIGN ⁇ L_REQUEST), on the other hand these signals must be projected onto the project-specific application, i.e. the signals must be routed to the appropriate hardware (DI ⁇ _SIGN ⁇ L_R ⁇ UTING). Requested hardware pins must also be configured (DI ⁇ _SIGNAL_IMPLEMENT).
  • the relevant configuration parameters for the component drivers of the DE can be presented in an abstract and project-independent manner. For digital input and output signals, the signal name, the direction and the initialization value are of interest at this level. From the point of view of the component drivers, it does not matter (provided the general conditions are met) on which hardware the component driver is to run later.
  • the configuration of the HAL includes the routing of the signal name to the corresponding hardware.
  • a generic hardware pin name is assigned to the signal.
  • the hardware-specific configuration settings are made at the lowest level.
  • the configuration parameters at this level relate to the corresponding module or signal class and can no longer be viewed independently of the project and hardware.
  • the signals are assigned by specifying the hardware module (e.g. ⁇ DC, GPIO or CY310, CY100, etc.) with the desired port or pin on this module.
  • the hardware module e.g. ⁇ DC, GPIO or CY310, CY100, etc.
  • the threshold voltage that decides high or low must also be specified.
  • Register values are set via the configuration of the port hardware layer. At this level, cross-module requirements come together. For example, there are different requirements for the parallel interface
  • the DIO configuration therefore takes place at different configuration levels:
  • the division of the configuration into different levels is not only limited to the configuration of digital input and output signals or the DIO module, but also in others
  • Modules are configured according to the above classification including any deviations.
  • the names of the XML configuration files are freely selectable. A multitude of package-oriented configuration files will certainly be created within the DE. On
  • signal routing can be distributed either in a central XML file or in different configuration files. It still has to be determined which division is best suited for structuring the project-specific configuration. The same applies to the setting of the hardware or register configurations.
  • each package requests a signal from the DE.
  • Each package can create one or more XML files with any file name and request or reserve digital input and output signals from the CoreZHwe / Dio module.
  • To the package syntax must be copied from the XML description for DIO (package layer - DE) into these XML files and adapted.
  • a signal with the name "E_A_BSK” is used in the "DIO” package, it has a specific direction (here "IN” for input) and can be applied (Applicable means that the signal routing is based on the runtime a signal table takes place and can therefore be changed during operation. If the signal data is only determined at compile time, signals can no longer be redirected at runtime.) or not (here "TES" for applicable).
  • the configuration of various signals can be repeated as often as you like in an XML file.
  • the DIO_CALIBRATION and DIOJNIT tags are optional tags. These should only be defined if requirements for access type or initialization already exist in advance from the DE layer. These tags are a request to the
  • the signal routing is carried out by the project at this level.
  • the software signal name is assigned to a hardware pin name, so to speak. This hardware pin name results from the desired hardware resource, which is configured in the hardware layer (see configuration of the hardware layer). In the example from the XML description for DIO (project layer.
  • the hardware properties of the TC1775ZTC1796 are separated from the functional settings and defined in a separate configuration layer (HW layer).
  • Each project can create one or more XML file (s) with a clear file name and
  • modules and their ports and pins power amplifiers and pins. These modules must be functionally capable of reading and outputting digital signals. To do this, the syntax from the XML description for DIO (hardware layer) must be copied and adapted in these XML files.
  • This module requests the resource (port "8", pin “0") and assigns the application identifier "YES” and the initialization value "HIGH” (if this makes sense for an input at this point).
  • the configuration of various signals can be repeated as often as you like in an XML file.
  • the hardware pin name is a purely generic name, which is uniquely assigned to a hardware resource and compiled according to the following pattern.
  • GPIO_P8_P0__IN For example, GPIO_P8_P0__IN.
  • the hardware pin name can be found in the DIO report file after a configuration run (see the generic hardware pin name below).
  • HW signal GPIO_P9_P4_IN
  • HW signal GPIO_P9_P8_IN module: GPIO
  • the saved XML files After performing the configuration according to the request of a signal and routing of a signal, the saved XML files must be in the respective makefiles under the element
  • the configuration data is entered via an XML browser (e.g. XMetal).
  • XML browser e.g. XMetal
  • DTD Document Type Definition
  • the DTD for the configuration of the mini project is on the edc_hwe vob in the mini project under ⁇ scripts ⁇ xml ⁇ medcl7_co ⁇ f.dtd.
  • This DTD is used by the Developers of the core packages (modules) gradually expanded according to the configurable data provided.
  • the XML configuration files must be checked for plausibility using this DTD.
  • the corresponding layer model is shown in FIG. 11.
  • a signal request is made to the DIO signal class.
  • the initialization value and the parameter applicability it is the signal name that is used to link the request from the DE with the routing in the HAL.
  • the signal name can now be routed to the corresponding resource in the HAL.
  • the mapping with the settings in the HWL takes place via the
  • Signal name or hardware pin name of the pin In addition to the module name, the corresponding port or pin must also be specified in the hardware layer.
  • the properties for the PORT hardware e.g. Controller settings are made separately via the PORT configuration.
  • the configuration of the individual layers is usually distributed to different XML files. The configuration generators have that

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Mechanical Engineering (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)

Abstract

L'invention concerne un dispositif de commande (100) et un programme informatique destiné à commander une unité d'entraînement (300) d'un véhicule. De manière traditionnelle, ledit appareil de commande (100) présente de nombreuses unités fonctionnelles, par exemple une unité fonctionnelle d'entraînement, un coordinateur moteur, un gestionnaire de diagnostic, etc. L'objectif de l'invention est de ne pas changer toutes les unités fonctionnelles ou une grande partie de celles-ci, mais de changer uniquement les unités fonctionnelles utiles pour la nouvelle unité d'entraînement, lors d'un changement de l'unité d'entraînement à commander à partir du dispositif de commande. A cet effet, une modularisation desdites unités fonctionnelles est utilisée. Cette modularisation permet de rassembler les unités de fonctions, ce qui permet une programmation individuelle du disque dur du dispositif de commande, de sorte que le disque dur est en mesure de communiquer avec les modules de l'appareil de commande (100).
EP04712578A 2003-02-21 2004-02-19 Appareil de commande et commande d'une unite d'entrainement d'un vehicule Withdrawn EP1597641A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10307698 2003-02-21
DE10307698A DE10307698A1 (de) 2003-02-21 2003-02-21 Steuergerät und Compterprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs
PCT/EP2004/050165 WO2004077180A1 (fr) 2003-02-21 2004-02-19 Appareil de commande et commande d'une unite d'entrainement d'un vehicule

Publications (1)

Publication Number Publication Date
EP1597641A1 true EP1597641A1 (fr) 2005-11-23

Family

ID=32797679

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04712578A Withdrawn EP1597641A1 (fr) 2003-02-21 2004-02-19 Appareil de commande et commande d'une unite d'entrainement d'un vehicule

Country Status (7)

Country Link
US (1) US20080119977A1 (fr)
EP (1) EP1597641A1 (fr)
JP (1) JP2006518436A (fr)
KR (1) KR20050103498A (fr)
CN (1) CN1754135A (fr)
DE (1) DE10307698A1 (fr)
WO (1) WO2004077180A1 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6645261B2 (en) * 2000-03-06 2003-11-11 Cargill, Inc. Triacylglycerol-based alternative to paraffin wax
DE102004046874A1 (de) * 2004-09-28 2006-04-13 Robert Bosch Gmbh Verfahren zum Betreiben eines Verwaltungssystems von Funktionsmodulen
DE102007038190B4 (de) * 2007-08-13 2009-07-02 Siemens Ag Verfahren zur Parametrierung eines Diagnosegerätes, korrespondierendes Computerprogramm und Computerprogrammprodukt sowie Diagnosesystem
DE102009002900A1 (de) * 2009-05-07 2010-11-11 Robert Bosch Gmbh Verfahren zum Konfigurieren eines Steuergeräts
KR101018034B1 (ko) * 2009-05-27 2011-03-02 주식회사 카네스 차량용 통합 이씨유 장치
EP2513456B1 (fr) * 2009-12-18 2015-02-25 Conti Temic microelectronic GmbH Calculateur de surveillance destiné à un appareil de commande
FR2956440B1 (fr) * 2010-02-17 2012-05-25 Peugeot Citroen Automobiles Sa Procede de controle commande d'un groupe motopropulseur d'un vehicule automobile
DE102010063326A1 (de) * 2010-05-25 2011-12-01 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Stellgebers mit einem bürstenlosen Elektromotor
US8933778B2 (en) * 2012-09-28 2015-01-13 Intel Corporation Mobile device and key fob pairing for multi-factor security
CN103064409A (zh) * 2012-12-21 2013-04-24 李萍 用于汽车仪表的dsc检测系统
CN103093777B (zh) * 2012-12-28 2015-12-23 Tcl康钛汽车信息服务（深圳）有限公司 一种采用Android系统控制DVD设备的方法及系统
JP6079577B2 (ja) * 2013-11-18 2017-02-15 トヨタ自動車株式会社 車両ドア制御装置
DE102016121818A1 (de) * 2016-11-14 2018-05-17 Torqeedo Gmbh System zum Betrieb eines mit einem Elektromotor ausgerüsteten Boots

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995034437A1 (fr) * 1994-06-10 1995-12-21 Siemens Aktiengesellschaft Dispositif de commande pour un vehicule
JP3460593B2 (ja) * 1998-09-17 2003-10-27 株式会社デンソー 車両用制御装置
DE10036643B4 (de) * 2000-07-26 2005-12-22 Robert Bosch Gmbh Verfahren und Vorrichtung zur Auswahl von Peripherieelementen
DE10052570A1 (de) * 2000-10-23 2002-04-25 Bosch Gmbh Robert System zur Steuerung von Betriebsabläufen

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004077180A1 *

Also Published As

Publication number Publication date
DE10307698A1 (de) 2004-09-02
JP2006518436A (ja) 2006-08-10
CN1754135A (zh) 2006-03-29
KR20050103498A (ko) 2005-10-31
US20080119977A1 (en) 2008-05-22
WO2004077180A1 (fr) 2004-09-10

Similar Documents

Publication Publication Date Title
EP1233888B1 (fr) Systeme electronique pour vehicule, et couche de systeme pour fonctions de fonctionnement
EP2587330B1 (fr) Dispositif de commande pour le fonctionnement autonome -au moins en partie- d'un véhicule et véhicule équipé d'un tel dispositif de commande
EP1597641A1 (fr) Appareil de commande et commande d'une unite d'entrainement d'un vehicule
EP0982193A2 (fr) Système de commande de l'entrainement d'un véhicule
DE10245926A1 (de) Bodenpedal mit Drehwinkelsensor
EP2422248A1 (fr) Système et procédé de répartition de données de projets d'une commande de sécurité d'une installation automatisée aux composants de commande
EP1671139A1 (fr) Systeme et procede pour tester des processus de commande dans un vehicule
DE102009011156B4 (de) Vorrichtung zur Steuerung und Regelung eines Antriebssystems
DE102009011157A1 (de) Vorrichtung zur Steuerung und Regelung eines Antriebssystems
DE102009011429A1 (de) Vorrichtung und Verfahren zur Steuerung und Regelung eines Antriebssystems
EP1055547B1 (fr) Système de commande des éléments de propulsion d'un véhicule ferroviaire
DE19963210A1 (de) Verfahren und Vorrichtung zur Steuerung eines Fahrzeugs
EP1639416A1 (fr) Unite de commande electronique et procede de definition d'une architecture de logiciel pour une unite de commande electronique
EP4433344B1 (fr) Appareil de commande pour un véhicule et procédé de commande d'un véhicule
DE102009011431A1 (de) Vorrichtung zur Steuerung und Regelung eines Antriebssystems
DE102004008869A1 (de) Steuergerät und Computerprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs
DE102007050771A1 (de) Kraftfahrzeugsteuerungssystem
DE102019006719A1 (de) Verfahren und System zum Überwachen einer funktionalen Sicherheit einer Antriebskomponente
DE10308458A1 (de) Steuergerät und Computerprogramm zum Steuern eines Antriebsaggregates eines Fahrzeugs
DE102012208765B4 (de) Verfahren zum Überwachen eines Verbrennungsmotors, der mindestens zwei Teilmotoren umfasst, Steuervorrichtung, Verbrennungsmotor sowie Fahrzeug
DE10332113A1 (de) Steuergerät und Netzwerk für eine Mehrzahl von Vorrichtungen
DE102009029394A1 (de) Stellervorrichtung, Steuergerät zum Betreiben der Stellervorrichtung und Verfahren zum Betreiben einer Stellervorrichtung
DE102019132428A1 (de) Funktionsorientierte Elektronik-Architektur
EP1685018B1 (fr) Procede de commande d'une unite d'accouplement
DE102008000578A1 (de) Verfahren und Anordnung zur Steuerung eines Fahrzeuges mit Hybridantrieb

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050921

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT

17Q First examination report despatched

Effective date: 20071102

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080313