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—Programme-control systems
  • G05B19/02—Programme-control systems electric
  • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
  • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
  • G05B19/0428—Safety, monitoring
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
  • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
  • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
  • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
  • G06F11/0751—Error or fault detection not based on redundancy
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/36—Preventing errors by testing or debugging software
  • G06F11/3668—Software testing
  • G06F11/3672—Test management
  • G06F11/3684—Test management for test design, e.g. generating new test cases
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/36—Preventing errors by testing or debugging software
  • G06F11/3668—Software testing
  • G06F11/3672—Test management
  • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
• • 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/23—Pc programming
  • G05B2219/23188—Software independent and dependent of hardware
• • 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/24—Pc safety
  • G05B2219/24006—Code coverage memory:contains data about addressed addresses during program run
• • 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/24—Pc safety
  • G05B2219/24034—Model checker, to verify and debug control software
• • 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/24—Pc safety
  • G05B2219/24038—Several test signals stored in memory and used as input signals
• • 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/24—Pc safety
  • G05B2219/24061—Simulator, generates input signals, shows output signals of logic

Definitions

• the invention relates to a method and a system for verifying software functions for a control unit according to the independent claims. Furthermore, the invention relates to a computer program consisting of program code elements for executing a method for software verification according to claim 10.
• the microcomputer In order to be able to determine the code coverage of a control or regulation program of the microcomputer even while the motor vehicle is traveling, it is proposed that the microcomputer contain a code coverage memory in addition to and parallel to the program memory and data memory, which is connected to the microprocessor via the address bus and the data bus , Information about which addresses of the program memory or the data memory are addressed by the microcomputer during the execution of a control program from the program memory during a drive of the motor vehicle as part of a write or read access can then be stored in the code cover memory.
• the so-called code coverage method for determining the code coverage is carried out by a so-called system execution analyzer.
• control unit software will also control and monitor safety-relevant driving functions in the near future, such as in X-By-Wire systems, the quality requirements for software development and verification in embedded control systems will continue to increase.
• the aim of the invention is to use a precisely defined, continuous function development process to specify a method for verifying the software functions or the software code, with which the quality of the software can still be ensured in order to optimize the situation resulting from the prior art.
• a system for verification and a corresponding computer program are the subject of the invention.
• the invention relates to a method and a system and a corresponding computer program for verifying software functions for a control unit using a simulation model for mapping the software functions and the control unit, advantageously from the identical simulation model on the one hand for a first experimental control unit and on the other hand for one second series control unit, the software code for the software functions is generated automatically, with identical input variables for the software functions being used on both control units and the resulting output variables of both control units being recorded synchronously, that is, simultaneously, the software functions being verified by comparing the output variables of both control units.
• a uniform simulation model for the experimental control unit, that is to say the experimental target, and for the series control unit, that is to say the ECU target, is thus taken as a basis.
• a so-called target-identical prototyping takes place, as mentioned, in the simulation model, e.g. B. ASCET-SD, modeled functions on the experimental target and the stimulation of the functions by the control unit input variables.
• the implementation for the software functions from the identical model for the series control unit, that is to say the ECU target also takes place automatically from the simulation model with the aid of a target code generation. The verification is then carried out by a parallel function test on the experimental target and ECU target.
• the acquisition and comparison of the output variables and / or intermediate variables leading to the output variables from the series control unit, that is to say the ECU target, are advantageously carried out with those of the experimental target or the Experimental control unit automatically performed by the experimental control unit.
• the software code for the software functions for each experimental control unit and series control unit is advantageously generated with different generating means, that is to say in particular translated with different compilers either for the same processor or for different processors.
• the code coverage that is to say the continuous paths in the software code and / or in the software functions for determining the
• the software functions serve to control operating sequences in a vehicle and are then verified accordingly with the method, the system and the corresponding computer program.
• the entire verification of the software functions is carried out with a simulation means simulating a vehicle and / or vehicle components and / or vehicle functions, for example LabCar, without the use of a real vehicle.
• the software code of the software functions is advantageously divided into hardware-dependent software code and hardware-independent software code.
• the hardware-dependent part includes, for example, that Operating system and the so-called hardware abstraction layer for defining general standardized interfaces for connecting to this hardware-dependent software code part for various, selectable, hardware-independent software code parts, the hardware-independent software code part containing the software functions for controlling the operating processes in a vehicle.
• this also creates a multi-stage function development process with which the software quality can be increased in every phase and the development risk can be minimized, which entails great potential for cost savings.
• FIG. 1 shows a series control unit, that is to say an ECU target and an experimental target, with a representation of the respective software architecture.
• FIG. 2 shows the flow of the method for software verification in a flow chart.
• FIG. 3 shows the data and control flow, based on the method for software verification according to the invention.
• FIG. 1 shows a series control unit 100, the so-called ECU target, and the experimental control unit 101, the so-called experimental target. Both control units 100 and 101 are connected via the communication link 103. Depending on the application, this communication connection can be unidirectional or bidirectional, serial or parallel, etc. Furthermore, a visualization and / or evaluation means 102 is connected to the experimental target 101, which is also referred to below as a GUI or Graffical User Interface. The connection itself, in parallel or serial as well as unidirectional or bidirectional, is designated 104 here. As already mentioned, this visualization means 102 can also include evaluation options, that is to say a computing unit and / or a storage unit, wherein this GUI can also be integrated in the experimental target.
• evaluation options that is to say a computing unit and / or a storage unit, wherein this GUI can also be integrated in the experimental target.
• Blocks 105 and 106 symbolically represent the ECU software architecture and the software architecture of the experimental target.
• the architecture of the software or the software functions of the series control unit, that is to say the ECU software is of central importance, for example for the formation of components and variants, the reuse and portability and the support of interfaces of the series control unit for development tools.
• the development process and the software architecture must therefore be considered together. There is one
• Layer architecture is advantageous, in which the actual control unit functionality, that is to say the hardware-independent software functions such as application software, is separated from the hardware-dependent software layers of the platform software.
• the platform software can be reused across projects, and secondly, the interfaces for the Unified access to the control units.
• This makes it possible to use standardized methods or tools tailored to these standard interfaces during development, verification, but also in production and service. B. for rapid prototyping, debugging, measuring and calibration.
• the functions of the application software or the software functions, in particular for controlling operating processes in a vehicle can be specified independently of the hardware and can thus be ported to different control unit platforms.
• Block 105 contains, for example, a block of data 107 which comprises the entirety of the data, that is to say input and output variables, measurement data, internal intermediate variables, etc. These data of the functions are essentially the same in the context of the software functions in block 107 and block 109. In software block 105, however, further software code or further software functions are no longer directly accessible, so that block 108 shows black box behavior and essentially only measurement and calibration, based on data block 107, is possible on the ECU target.
• Experimental target 101 is used, in which access to the behavior of the functions or the software functions in block 110 is also possible in addition to data block 109 within the framework of the hardware-independent software.
• black box behavior is therefore only shown in block 111, that is to say with regard to the platform software.
• the operating system for example OSEK-OS or ERCOS, as well as automotive services and the mentioned abstraction layer, hardware abstraction layer HAL, are embedded in it. Through this abstraction layer, the independence of the software layers above, in particular the application software that describes or contains the behavior and data of the software functions.
• the software structure is essentially between the series control unit, that is to say the ECU target and the experimental target, that is to say the
• Experimental control unit the same. It is also important, in order to describe it later, to represent the time synchronism as part of the verification, the operating system or the operating systems on which they are based having the same time behavior, advantageously using the same or comparable operating systems, in particular standard operating systems such as OSEK and other standards such as ASAM are taken into account and used.
• Development tools such as ASCET-SD, support the graphic, physical and component-based modeling of functions of hardware-independent software, in particular the application software, simulation and rapid prototyping with an experimental target, i.e. target-identical prototyping and automatic target code generation for implementation on the Serial control unit, the target system.
• the simulation model or the corresponding development tools generate a complete description file in a standard format, for example ASAM-MCD2, for all measurement and calibration variables of a control unit, which enables standardized measurement and calibration tool interfaces.
• the process sequence is shown in FIG. 2 based on the creation of the simulation model in block 200.
• the simulation model in particular ASCET-SD, is in particular for the hardware-independent software functions “single source”, that is, the basis for the series control unit, that is, the ECU target and the experimental control unit.
• the target code is generated in block 201 with respect to the ECU target for the software functions from the simulation model for the series control unit formed in block 200.
• Target-identical prototyping of the functions modeled in the simulation model is also carried out automatically on the experimental target.
• Target-identical prototyping means that the entire arithmetic and timing behavior is specified and simulated (on the experimental control unit) and virtually matches the system behavior of the series control unit.
• the software code is then generated in block 203, in particular by compiling it in C for the ECU target.
• the software code can be in any programming language, the example C as well as C ++ or Java, etc. are not to be understood as restrictive with regard to the subject matter of the invention.
• the conversion into the software code mentioned for the experimental control unit takes place.
• the actual software verification now takes place in block 208 and block 209.
• a temporally parallel function test is carried out in block 208 on series control unit 205 and experimental control unit 206, wherein, as indicated, a data exchange can take place via connection 207.
• Experimental control unit identical. For example, e.g. Floating point arithmetic of the experimental target (e.g. also fixed point arithmetic possible) and, for example, fixed point arithmetic on the series control unit, a comparison between floating point arithmetic and fixed point arithmetic is possible. It is thus possible at an early stage to investigate the influence of quantization and overflow effects on the series control device, that is to say the ECU target, in order to make it possible to display deficiencies in the implementation and, in particular, to correct them automatically, if necessary.
• the measurement and comparison of the output variables with regard to the software functions then takes place, preferably on the experimental control unit.
• the measurement on the series control unit and experimental control unit or the acquisition of the values and their comparison takes place simultaneously and synchronized in time.
• software verification with target-identical prototyping and target code generation is possible.
• Identical code generator options for target identical prototyping and target code generation can be available, which means that fixed point arithmetic is then used on both targets and control units.
• the same operating systems, in particular an OSEK operating system, such as ERCOS and identical ones advantageously come on the experimental target Service routines, as in the series control unit, are used.
• a code coverage analysis is possible with block 210 either via connection 212 on the experimental target or optionally via connection 213 on the series control unit.
• the software code in particular C code, which is generated automatically by the simulation model, is instrumented.
• commercial coverage tools for code instrumentation or for coverage analysis can be integrated into the simulation model in order to achieve the goal of achieving a high coverage (path and / or branch coverage).
• 100% branch coverage on the ECU target can be inferred from 100% branch coverage.
• the code coverage analysis could also be carried out on the ECU target, as shown via connection 213, in which case it would be advantageous for the code coverage analysis to be carried out directly on the software code of the series control unit, and thus also hardware-dependent software part, the platform software, is covered.
• the measurement and simulation environment is advantageously integrated into the experimental control unit and could also be used in the laboratory, on the test bench and in the vehicle.
• the measured variable comparison that is to say the comparison of the output variables, is advantageously calculated on the experimental control unit. Due to the diversity of the platforms used, including compilers and code generator sets, the examination and review of code generator optimizations especially for the series control unit, the identification of code generator, compiler and processor problems or errors as well as the detection of timing problems of the series control unit are possible. This will now be explained in more detail using the data and control flow in FIG. 3.
• FIG. 3 shows the experimental control unit with block 101 and the series control unit again with block 100.
• the serial control unit 100 receives specific input variables via connection 303 and outputs output variables or measured variables via connection 302 in accordance with the software functions.
• Block 300, the control route can, on the one hand, as already mentioned, be the vehicle; on the other hand a simulation environment such as B. the representation of various vehicle functions or the entire vehicle in the laboratory as a LabCar, which means that the entire test sequence together with such a LabCar can be relocated to the laboratory and automated.
• the input variables of the real series control unit can be, for example, via the bidirectional connection 103 or alternatively with the connection 304
• the line 301 or the symbolic signal flow represents, for example, a trigger from the ECU target to the experimental target.
• the output variables of the series control unit can be transmitted via path 306 to a visualization and, under certain circumstances, evaluation system 102 GUI, which in particular is bidirectionally connected to the experimental control unit via connection 104 communicates.
• the GUI can also be integrated into the experimental control unit.
• the output variables of the experimental target or also the comparison results can optionally be transmitted via a path 305 to further evaluation means or display means. Especially in the
• Program code elements are processed in order to achieve the method steps according to the invention.
• the program code elements that run or are executed when executed on a computer, computer or the verification system then result in the described method steps of the system according to the invention.
• the program code elements are stored on any data carrier (system-internal or external), ie RAM, ROM, EPROM, CD-ROM, floppy disk, etc., before or for execution.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Quality & Reliability (AREA)
• General Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Automation & Control Theory (AREA)
• Debugging And Monitoring (AREA)
• Stored Programmes (AREA)
• Testing And Monitoring For Control Systems (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=7698161

Family Applications (1)

Country Status (6)

Families Citing this family (24)

Family Cites Families (11)

• 2001
  • 2001-09-07 DE DE10144050A patent/DE10144050A1/de not_active Withdrawn
• 2002
  • 2002-07-24 EP EP02760105A patent/EP1428126A2/de not_active Ceased
  • 2002-07-24 JP JP2003531322A patent/JP4236104B2/ja not_active Expired - Fee Related
  • 2002-07-24 AU AU2002325798A patent/AU2002325798A1/en not_active Abandoned
  • 2002-07-24 WO PCT/DE2002/002725 patent/WO2003027850A2/de active Application Filing
  • 2002-07-24 US US10/489,070 patent/US7275184B2/en not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events