Title of Invention | PROCESS FOR TESTING A CONTROL UNIT CONFIGURATION |
---|---|
Abstract | In the case of a system (6) for testing a control unit configuration comprising at least one control unit (11) and at least one sensor (1), whereby the control unit (11) and sensor (1) and possibly other bus subscribers are connected to one another by a data bus and, whereby a test signal is uploaded to one of the bus subscribers to test the control unit configuration, it is proposed that at least one of the bus subscribers, particularly a sensor (1) be substituted by a corresponding emulator (3) of this bus subscriber. (Figure 2) |
Full Text | SYSTEM AND PROCESS FOR TESTING A CONTROL UNIT CONFIGURATION Technical Area The invention is with regard to a system as well as a process for testing a control unit configuration comprising at least one control unit and one sensor, whereby the control unit and sensor and possibly other bus subscribers are connected to one another by a data bus and whereby a test signal is uploaded to one of the bus subscribers in order to test the control unit configuration. These types of systems can be employed particularly to test vehicle systems. Vehicle systems such as ESP (Electronic Stability Program) for anti-slip control, TCS (Traction Control System) for traction control, ABS (Anti-blocking System) for brake control use such control unit configurations, which are employed increasingly in modern motor vehicles. Factors are assigned to the vehicle system through a control unit with the help of corresponding sensors and complex signal processing. Prior Art A system with which to upload simulation data to a control unit and with which to process the simulation data is established in DE 197 11 734 C2. Using the concrete example of an air-bag control unit, the theory of this patent specification proposes to permit the uploading of analogue simulation signals (crash signals) as well as communication with the control unit and control of the control unit by means of a single computer. The earlier separate computer used for uploading stimulation signals as well as the conversion and scaling of crash simulation data undertaken in this connection can thus be dispensed with (due to already existing compatibility of the one computer). Signal uploading of the analogue simulation signals takes place at that location where the signal of the speed sensor is uploaded in a real case. Signals produced by the control unit due to simulation, which activate corresponding actuators in normal operation, are measured and evaluated by the same computer. A process is furthermore established in DE 101 11 266 CI for checking an interface module. Checking is initiated here by a processor by transferring a first data telegram to the interface module mentioned. The interface module is moved into a test mode by the same in which it no longer transfers sensor data that it receives from a sensor in normal operation but, in fact, transfers stored test values from registers to this processor. These test sensor values run through the associated processing process, whereupon the processor activates another unit such as an ignition circuit activation. The ignition circuit activation on its part thereafter activates actuators, namely restraining agents, without resulting in an activation in the test mode. A complete test of the processing of the sensor values can thus be executed in the control unit using the test sensor values from the registers of the interface module proposed here. Multiple usage of sensor signals by several vehicle systems is established in DE 100 49 526 C2 and DE 100 56 549 C2. External influences are measured by sensors at and in the vehicle from which the current driving situation can be concluded upon for vehicle systems already mentioned initially. Each regulator of a vehicle system receives a default set value e.g., from the driver and, in turn, produces activation signals for actuators. An estimation module is proposed in the documents mentioned that measures external set values via existing sensors and generates actual values as regulating variables. The multiple computing of vehicle-relevant variables can be dispensed v^ith, as a result, in the individual vehicle systems. it has become apparent since some years that an analogue signal uploading such as is the subject matter of DE 197 11 734 C2 mentioned, has reached the limits of its usability for testing a control unit configuration. Signal uploading to sensors that are continually becoming more complex and intelligent is filled with more risks despite advances in technical developments. This is substantiated, on the one hand, by development itself since more and more protective mechanisms and control circuits render sensors less sensitive to disruptions and external influences. In addition, there is the forward displacement of the digital signal processing to the physical signal sensors such s e.g. to the integrated Sigma/Delta converter that simultaneously triggers the signal sensor (capacitive seismic comb). And finally, costs that must be taken into consideration for test and stimuli inputs at each sensor in the field must not be ignored. These types of additional inputs can, however, simultaneously influence the behaviour of the sensors negatively. Input variable processing through analogue stimulation is always technically difficult to implement for the reasons mentioned and, additionally, there can be no guarantee that no costs or complexity will be involved. The signal-to-noise ratio, internal noise, disruptive influences as well as inaccuracies hinder technical implementation while reproduction of the desired behaviour deteriorates steadily. In addition, test standards of vehicle systems, for example, keep getting higher since high security standards, client requests as well as systems that are becoming more complex have to be taken into consideration. There is, accordingly, a requirement for a system and a process for testing a control unit configuration with at least one control unit and at least one sensor, especially for vehicle systems, that facilitates testing with high reliability in a justifiably simple manner with regard to a technical aspect. Presentation of the Invention Substituting an original bus subscriber, in accordance with the invention, with a corresponding emulator of this bus subscriber in a test case, results in a more secure and precise test than by substitution with the hitherto established simulation of this bus subscriber. While general experiments are carried out on a model based on reality in the case of a simulation, the system itself is functionally re-created in the case of an emulation. The result counts first and foremost in the case of a simulation while other aspects that play only a marginal role in the questions (presumably) to be answered, can be simplified or omitted completely. In the case of emulation, however, the re-created system receives the same data, executes the same programs and achieves the same results as that of the re-created system. The emulator i.e., the system, that emulates another one can, with advantage, be operated with the factory-provided original code, can receive the same stimuli as the re-created system does and, depending upon the structure, can contain additional options. The most important functions of the original bus subscriber are re-constructed as real by the emulator. Emulation is thus not only more secure and precise than simulation, the emulator in accordance with the invention is in fact more efficient, stable and flexible than the original subscriber. It is an advantage when that bus subscriber to which the test signal is uploaded, is substituted by its corresponding emulator. Here it is especially expedient to use an emulator of a sensor for testing a control unit configuration. To facilitate better visualisation, the invention is described below by means of a sensor-emulator whereby, without curtailing the commonality, this sensor-emulator should be representative of a module/component of a control unit configuration i.e. common to a bus subscriber of such a control unit configuration that communicates through a data bus.. The following entities are relevant if the sensor is considered in the sense mentioned : 1. The physical bus coupling/bus type 2. Protocol creation 3. Output variable processing 4. Logic/control such as 5. The input variable processing Emulation of the logic/control, output variable processing and protocol creation can be taken over from the original bus subscriber, whereby this take-over is based on porting the, for example, VHDL module, to the emulator hardware. Such VHDL modules (=VHSIC hardware description language, whereby VHSCI=very high speed integrated circuit) are used often today to describe complicated digital systems, whereby this hardware description language describes the required behaviour of a circuit at a higher abstract level without having to work with individual electronic components. Again, without curtailing the commonality in the following, VHDL code or VHDL modules should be spoken of primarily in order to explain the sensor-emulators, whereby the invention is not restricted to this type of hardware description. Porting of the VHDL module mentioned ensures that processing in the emulator is on par with the original with regard to reaction, timing and duration. Input variable processing can also be taken over to a large extent especially if the same deals with filtering as well as with a signal-processing component. Consequently, only one processing level that is responsible for coupling the bus subscriber (sensor) to be emulated to the control unit configuration is substituted in the emulator by an individually usable processing level. What has been said demonstrates that the emulator in accordance with the invention takes over characteristics of the original bus subscriber and has more possibilities than the original bus subscriber due to its individually usable processing level as well as other individually usable components. The degree of freedom of the tests is increased in particular. In this manner, the emulator has the possibility, for example, to provide filtered or unfiltered physical input variables as well as status and error information through an own buffer memory, so that any behaviour of the original bus subscriber can be re-set over a defined period (subject to memory size and to signal). One or all bus subscribers can be scanned and their behaviour registered by the emulator in an advantageous design. One speaks of a so-called eavesdropper in the case of this function. One of the biggest advantages of this procedure in accordance with the invention is the use of as many original modules (e.g. in the VHDL code) as possible. This facilitates the greatest possible confidence in clients with regard to the tests and the verification of the control devices. It is an advantage when the emulator has the following components: 1. An efficient FPGA (Field Programmable Gate Array): this deals with a freely programmable logic circuit and, hence, with the heart of the emulator; 2. If necessary EEPROM/Flash memory: this hereby deals with a memory module that can be electronically deleted and programmed in which each byte can be deleted and written individually and/or data can be deleted and written only block-wise; 3. SD-RAM (Synchronous Dynamic Random Access Memory) as a special type of main storage: other types of main storages are also possible in principle; 4. Various bus transceivers for sending and receiving signals via the data bus, coupling to the bus level and level conversion; 5. USB and/or Firewire co-controller, here as a special form of a human interface input, for example, of a control PC in an emulator; 6. AD converter for conversion of analogue signals into digital, especially if analogue signals are to be uploaded to the emulator; 7. DAC converter for conversion of digital signals into analogue ones, especially if the control unit receives analogue signals from the emulator or if test results are to be issued in analogue form; 8. Timer, especially if the emulator is to use a clock pulse other than the system's clock pulse; 9. Digital I/O (e.g. trigger) for initialising the system as well as to pause or cancel; here too, the same deals with a type of human interface. The input variables for the respective bus subscriber to be emulated can be transferred directly in digital form to the SD-RAM with the help of the USB/Firewire interface. Data from the SD-RAM can, e.g., be transferred to an external computer (PC) in the reverse direction, should the emulator also be used as a scanner (eavesdropper). Data can, furthermore, be continually uploaded to the emulator with the help of the AD convertor. Analogue or digital uploading is consequently possible by means of an accompanying convertor. Simple monitoring or an analogue stimulus is thus achieved in the emulator. Due to the spatial separation of the emulated bus subscriber and the high data transfer rate, it is usually necessary to establish a transmission network with LVDS (= low voltage differential signal) / LVDM (= low voltage differential multipoint) drivers. Figures The invention and its advantages are explained in greater detail below with the help of exemplary embodiments presented in the figures. Figure 1 schematically illustrates various processing levels for input variable processing of an original bus subscriber Figure 2 schematically illustrates the various processing levels for input variable processing of an emulator that substitutes the original bus subscriber and Figure 3 presents a design of the system in accordance with the invention with which to test a control unit configuration. Preferred Designs Figure 1 schematically illustrates various processing levels or layer 2A, 2B, 2C of an original sensor 1 that acts in the place of a bus subscriber in a control unit configuration, that has at least one control unit and at least one such sensor 1. Control units and sensors as well as other bus subscribers are connected by a data bus via bus connection 5. Such control unit configurations are typically used in motor vehicle application, particularly to implement the vehicle systems ESP, TCS, ABS described initially. Processing level 2A of sensor 1 essentially contains components required for coupling to the data bus such as sensor head input, sensor signal processing and an AD converter for conversion of analogue input signals into digital signal sequences. The two processing levels 2B and 2C are responsible for subsequent signal processing. Processing level 28 comprises a filter module as well as units for setting a gain and an offset as well as possible other components. Processing level 2C comprises offset control, clipping, status register, error register, serial number (SN), state machine among others and is, therewith, particularly responsible for the internal signal conversion. The most current form today is implementation of such processing levels 2A, 28, 2C in the form of modular VHDL codes. In accordance with the invention, one or several bus subscribers are substituted by corresponding emulators for testing a control unit configuration. In this exemplary embodiment, sensor 1 is to be substituted by a sensor-emulator 3. As already mentioned, most of the relevant units for this, viz. the protocol creation, output variable processing and logic/control based on porting the corresponding VHDL modules to the emulator hardware of the original subscriber, are taken over. Emulation of the physical bus coupling and input variable processing as other relevant units is referred to at Figure 2. Figure 2 shows the corresponding processing levels in the sensor-emulator in a representation of Figure 1. Processing levels 48 and 4C thereby correspond to processing levels 28 and 2C of the original sensor 1. Input variable processing can thus be taken over to a targe extent. The emulator hardware contains the individually usable processing levels indicated by 4D, these levels processing the input variables as well as status and error information for the original modules in the same manner as the original input variable processing module. Processing level 4D, which substitutes processing level 2A of sensor 1, comprises the following components, for example: Three channels for analogue or digital 16-bit signal inputs (corresponding to three vehicle axes), a RAM as memory for each of the channels mentioned, an analogue-digital convertor (ADC) as well as a digital-analogue convertor (DAC), a USB (universal serial bus) connection for receipt of data, for example, from a control PC, an efficient FPGA such as, for example, a EPF10K50 or something larger such as a LVDS driver, for example, an SPI or PAS bus as well as, possibly, freely usable UART (universal asynchronous receiver/transmitter) for enhancements (CAN, ...). Other suitable components of the sensor-emulator 3 can be selected from components 1 to 9 listed above. Sensor-emulator 3 can provide filtered or unfiltered physical input variables as well as status and error information through an own buffer memory, so that any behaviour of the original bus subscriber, such as sensor 1, can be re-set over a defined period. In addition, as already mentioned, one or all other bus subscribers can be scanned by emulator 3 and their behaviour registered. A concrete exemplary embodiment of system 6 with which to test a control unit configuration is illustrated schematically in Figure 3. This hereby deals, for example, with a case of digital crash-uploading in airbag development. The control unit (ECU) is indicated by 11. In the present design in accordance with Figure 3, the characteristics of control unit 11 that is, for example, a component of a vehicle system, are tested. Test data, for example, sensor test data are fed to control unit 11 for this purpose. This test data is processed in control unit 11 and corresponding signals are issued from control unit 11 to, for example, actuators that are not illustrated. A database 7, a pre-processing module 8 as well as a control PC 9 are present in the set-up of test system 6, illustrated by way of example. Control PC 9 communicates with USB 15 of emulator 3 via a USB interface 22. In the case of emulator 3, the same deals with a bus subscriber of the control unit configuration to be tested, especially with a sensor-emulator. A contour generator 10 can, furthermore, be provided. The components of emulator 3 have already been described in detail above. Listing the numbers of the components in the remaining document will therefore suffice: RAM 12 with, for example, 3 x 2 MB is present, apart from USB (Universal Serial Bus) 15. Three channels are provided corresponding to the three vehicle axes, whereby three digital-analogue converters (DAC) 13 as well as three analogue-digital converters (ADC) 14 are provided. The FPGA is indicated by 16. A latch 17 stores internal information such as status, ID, error, number, ... One LDS driver 18 serves as a connection to a SPI bus, transmitter and receiver or transceiver 19 are provided for a PAS bus. The trigger input is indicated by 20, the trigger signal 21 is fed to the trigger input 20. An appropriate test routine is called up from the database 7 to test the control unit 11. This reaches a control PC 9 via a pre-processing module 8 for filter models and via signal pre-processing, control PC 9 being responsible for data transfer and control information. Test signals produced by control PC 9 are finally given via a USB interface 22 to the corresponding bus (USB) 15 in emulator 3. Sensor-emulator 3 now undertakes exactly the same signal processing and signal output as the original sensor and forwards a corresponding signal in an analogous or digital form to control unit 11. By means of the set-up illustrated in Figure 3, it is also possible to produce analogous signals as test signals from a contour generator 10, these test signals being uploaded to the analogue-digital converter 14 of emulator 3. The emulator illustrated is designed for uploading of analogue and/or digital test signals in this manner. The actual beginning of testing is actuated by a trigger signal 21 that is created at the trigger input 20 of emulator 3. Claims 1. System (6) with which to test a control unit configuration comprising at least one control unit (11) and at least one sensor (1), whereby control unit (11) and sensor (1) and possibly other bus subscribers are connected to one another through a data bus and, whereby a test signal for testing the control unit configuration is uploaded to one of the bus subscribers, characterised in that, at least one of the bus subscribers is substituted by a corresponding emulator (3) of this bus subscriber. 2. System in accordance with Claim 1, characterised in that, that bus subscriber to which the test signal is to be uploaded, is substituted by its corresponding emulator (3). 3. System in accordance with Claim 2, characterised in that, the emulated bus subscriber is a sensor (1). 4. System in accordance with one of Claims 1 to 3, characterised in that, the emulator contains a scanner function in order to register data from other bus subscribers. 5. System in accordance with one of Claims 1 to 4, characterised in that, the system has a computer (9) for data transmission and control information, this computer (9) having an interface (22) to the emulator (3). 6. System in accordance with one of Claims 1 to 5, characterised in that, the emulator (3) is designed for processing of digital and/or analogue input variables. 7. System in accordance with one of Claims 1 to 6, characterised in that, the emulator (3) is designed for output of digital and/or analogue output variables. 8. System in accordance with one of Claims 1 to 7, characterised in that, the emulator (3) has various processing levels (4D, 4B, 4C), whereby levels (4B, 4C) responsible for signal processing and/or signal filtering essentially correspond to those of the emulated bus subscriber. 9. System in accordance with one of Claims 1 to 8, characterised in that, a processing level (2A) is responsible for coupling the bus subscriber to be emulated to the control unit configuration through an individually usable processing level (4D) in the emulator. 10. Process with which to test a control unit configuration comprising at least one control unit (11) and at least one sensor (1), whereby control unit (11) and sensor (1) and possibly other bus subscribers are connected to one another through a data bus and, whereby a test signal is uploaded to a bus subscriber to test the control unit configuration, characterised in that, at least one of the bus subscribers is emulated by the corresponding emulator (3) of this bus subscriber. 11. Process in accordance with Claim 10, characterised in that, that bus subscriber to which the test signal is uploaded, is emulated. 12. Process in accordance with Claim 2, characterised in that, a sensor (1) of the control unit configuration is emulated. 13. Process in accordance with one of Claims 10 to 12, characterised in that, the emulator (3) is used as a scanner to register data of other bus subscribers. 14. Process in accordance with one of Claims 10 to 13, characterised in that, the transfer of data and of control information to the emulator (3) is undertaken through a computer (9). 15. Process in accordance with one of Claims 10 to 14, characterised in that, digital and/or analogue input variables are uploaded to the emulator (3). 16. Process in accordance with one of Claims 10 to 15, characterised in that, digital and/or analogue output variables are issued from the emulator (3). |
---|
Patent Number | 268423 | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Indian Patent Application Number | 3961/CHENP/2007 | |||||||||
PG Journal Number | 36/2015 | |||||||||
Publication Date | 04-Sep-2015 | |||||||||
Grant Date | 29-Aug-2015 | |||||||||
Date of Filing | 11-Sep-2007 | |||||||||
Name of Patentee | ROBERT BOSCH GmbH | |||||||||
Applicant Address | POSTFACH 30 02 20, D-70442 STUTTGART | |||||||||
Inventors:
|
||||||||||
PCT International Classification Number | G06F 11/26 | |||||||||
PCT International Application Number | PCT/EP06/60553 | |||||||||
PCT International Filing date | 2006-03-08 | |||||||||
PCT Conventions:
|