DE102009054137A1 - Method for testing application utilized to develop functionalities of e.g. dynamic traction control of motor vehicle, involves considering characteristics of software components to simulate expected temporal characteristics of application - Google Patents

Abstract

The method involves executing functionalities of software components of an application in calculation units (ECU1-ECU9), and simultaneously executing a part of the software components as a test configuration in a test calculation system (TR). Temporal characteristics of the software components are considered in the calculation units for simulating expected temporal characteristics of the application in a distributed calculation system during execution of the software components, and the characteristics of the application are evaluated.

Description

The invention relates to a method for testing an application, which is intended for execution in a distributed computing system with a number of connected via a communication network computing units, wherein the application is formed of a plurality of software components with a respective functionality that to their Execution are provided on the computing units of the computing system. In particular, the invention relates to a method for testing an application for a vehicle, in which the distributed computing system comprises a plurality of computing units that are communicatively connected to one another and designated as controllers.

In particular, in the development of vehicles, the problem is that an application, which is composed of a variety of software components, must be checked with regard to the interaction of the plurality of software components in the computing system. Depending on the application, a software component or a plurality of software components may be provided on a respective computing unit of the distributed computing system. If several software components are arranged on one arithmetic unit, they must share the available hardware resources when they are executed. The review includes on the one hand an analysis of the performance of the application and on the other hand an analysis with regard to its intended functionality. The verification is made more difficult by the fact that the computing units used to execute the application can differ greatly in terms of their hardware resources. The computing units differ z. As regards their processor, the available memory, the connection to a bus system, etc. Due to this, the computing units have a different runtime behavior.

Within the scope of the development process of a vehicle, functions to be integrated into the vehicle are model-based already in early development phases, ie. H. using simulation methods. The aim here is to avoid expensive integration tests of applications on the real vehicle. The integration tests are to be completely substituted by the use of available information technologies and test methods. The test procedures should emulate an integration test on the real vehicle as closely as possible. Due to the ever-increasing complexity of vehicle electrics and electronics, a disproportionate number of test cases have to be available and procedures simulated to ensure completeness in the testing of an application. As a result, the test effort grows exponentially analogous to vehicle complexity. It is already becoming apparent that the integration of applications for vehicles to be developed in the future can no longer be carried out manually on a test vehicle.

For testing the application, so-called non-real-time simulation environments are known, which integrate software components for the simulation of system components and synchronize with each other through software-based mechanisms. This is intended to map the behavior of the computing system to be examined with the application running thereon in a time-correct manner.

Real-time control systems are also known which allow dynamic, d. H. during runtime, load and link software components managed in libraries. Such control systems allow a simulation on a fixed hardware with an execution unit as a test computing system.

In addition, so-called. IT application server are known, which allow applications to integrate hardware independent in an integrated operating environment via script and there networked to run.

Also known are so-called hardware-in-the-loop test rigs that use scripts to stimulate real hardware and thus simulate real behavioral scenarios.

A disadvantage of the known method for testing an application is that the check either only with a special hardware, with non-integrable single modules or with insufficient performance, d. H. not in real time, is feasible. In addition, the execution times in a simulation are many times slower compared to the real computing system used. As a result, a time-synchronized integration of software-based simulation and real hardware components (that is, computing units) is not possible.

It is therefore an object of the present invention to specify a method with which the test of an application can be carried out realistically in a simple and cost-effective manner using information technology available.

The invention provides a method for testing an application that is intended for execution in a distributed computing system, in particular a vehicle, having a number of computing units connected via a communication network. The application is from one Formed a plurality of software components with a respective functionality, which are provided for their execution on the computing units of the computing system. In the method, at least a portion of the software components of the application is executed simultaneously as a test configuration on a test computing system, wherein in the execution of a respective software component whose temporal behavior on the computing unit on which the software component is to be executed , is taken into account to simulate the expected temporal behavior of the application in the distributed computing system. Subsequently, the behavior of the application is evaluated.

The method according to the invention enables a timely depiction of the behavior of the application to be tested, as it later behaves after integration into the distributed computing system, for example a vehicle. As a result, a safeguard of system components that use the application can be realized already in a very early phase, before the real computing units of the system may already exist. The integration of subsystems of the application can be virtually tested in advance of the realization in the real, distributed computing system. This involves greatly reduced vehicle integration performance, which can reduce development time and development costs for implementing an application.

According to an expedient embodiment, the execution code of a respective software component comprises a functional portion that includes the structure of the software components for execution on the real computing unit, and a portion for determining the runtime behavior on the real computing unit. In particular, the temporal behavior of the arithmetic unit on which the software component is to be executed is integrated in the execution code of a respective software component.

Likewise, the temporal behavior of the arithmetic unit, on which the software component is to be executed, can be determined during the execution of the software component.

Conveniently, the test computing system is operated with a real-time operating system. For example, as a real-time operating system Linux or a modification thereof can be used, whereby the synchronicity of the processes of the application can be provided. This makes it possible to simulate an application at least in real time. In one embodiment, it is provided that the real-time operating system emulates the operating system of a respective computing unit of the distributed computing system on which the application is to be used. The real-time operating system also provides a wide range of development tools that a developer or administrator can use to test the application.

According to a further embodiment, the functionality of a respective computing unit is provided logically by a task with a predetermined timing control (scheduling), in which one or more software components are executed.

The test computing system comprises a number of test computers, which in the case of several test computers are connected to one another via a communication system, wherein one or more tasks are executed on a respective test computer. As a test computer, a conventional PC can be used. The use of standardized computers (PCs, graphic cards, consumer electronic devices) enables the cost-effective provision of computing power. By a test computing system with a plurality of test computers, a much greater computing power can be provided compared to that of conventional vehicle test benches. Due to the basically selectable computing resources, a fully automatic testing is possible, which enables a strong reduction of the warranty costs. In addition, good scalability and cost-effective maintenance is ensured by simply exchanging or extending individual test computer in the test computing system.

According to a further embodiment, the temporal behavior of a communication path of the computer system, via which two software components exchange data during the execution of the application, is simulated as an independent software module and simulated in the test on the test computer system. A communication path may be, for example, a bus (eg, in accordance with the Ethernet protocol). A communication path may also relate to the local communication in a main memory of the simulated arithmetic unit. In this way, the actual temporal behavior of the application on the real, distributed computing system can be modeled with further improved precision.

A further embodiment provides that a dynamic integration of a respective software component and / or a software module into the test configuration of the test computing system, whereby different application scopes of the application can be checked. In particular, the omission of compiling at least some of the software components of the application for performing a test is possible. This leaves The development process for software-intensive functions in the distributed computing system is efficient and especially distributed. An effective synchronization is possible. As a result, for example, third parties can be technically integrated into the development process. A decrease of supplied software components can be done in an early phase after the performance of the test method according to the invention. The behavior of a supplied software component is both functional and precisely traceable to its resource requirements. Improvements are possible in a simple way, expensive changes in advance can be avoided.

A configuration data set is expediently created for a respective test configuration, with which the sequence and the transit times of the software components of a respective test configuration are determined, wherein the configuration data record is processed by a sequence control of the test computing system. The test computing system used for the simulation can be easily and accurately calibrated by using one or more configuration records corresponding to the distributed computing system being simulated. In particular, the method according to the invention makes it possible to modify the configuration data record at the runtime of the test. This allows a further simplification of the simulation method, since in the context of a test individual components can be replaced by alternatives, without the need for a complete test would have to be performed again. Rather, it is thereby possible to resort to already determined test values, which are then further processed by the modified software components.

It is further envisaged that a means for technical monitoring of given requirements will be integrated into the test environment.

The invention will be explained in more detail below with reference to an embodiment in the drawing. Show it:

1 a schematic representation of a target system-dependent synchronization of two software components,

2 a schematic structure of a test computing system according to the invention for carrying out a method for testing an application,

3 a schematic representation of the use of a so-called integration layer,

4 a schematic representation of a timing control (scheduling) networked control devices, which are modeled in the form of operating system tasks,

5 a schematic flow diagram of an application comprising several software components, wherein a modification of a configuration data record carried out at runtime is carried out,

6 a schematic representation of the infrastructure for simulating and hedging electrical / electronic systems, as used for carrying out the method according to the invention, and

7 the schematic representation of an architecture of a test computing system according to the invention.

In the following exemplary embodiment, the testing of an application from a plurality of software components with a respective functionality is explained with reference to the application in a vehicle. In principle, however, the method according to the invention is not limited to such applications relating to motor vehicles but can be used for all those applications which are to be carried out in a distributed computing system.

A distributed computing system in a vehicle includes a number of computing units connected via a communications network. These arithmetic units are called control units (so-called Electronic Control Units). The communication network includes all types of data lines, such. B. data buses. One or more software components, which are executed by respective processors of the control devices, are respectively stored on the control devices. A plurality of (distributed) software components forms an application which is provided, for example, for forming the functionality of a dynamic traction control or an electronic stability system and the like. To provide the functionality of the application must, for example, from the software component of a control unit sensor data, such. As wheel speeds, speed, accelerations in the transverse and longitudinal directions are detected. A software component of another controller, these sensor data are supplied to the evaluation. One or more actuators are coupled to one or a respective further control unit, wherein the software components located or located thereon, depending on the result of the evaluation, actuate one or more of the actuators. To provide the functionality of an application is thus the Collaboration of a variety of software components necessary, which are located on a plurality of controllers of the distributed computing system. In this case, the resources provided by a respective control device (eg processor, memory, connected bus system) can differ considerably, so that different runtime behavior occurs during the execution of the software components on the different control devices. To provide the desired functionality of an application, this different behavior of the controllers must be taken into account.

In order to obtain a realistic behavior of the application when testing on a test computer system, a timely depiction of the behavior of the application is therefore important. Since the application, as explained, must run on the most diverse processor platforms of the control units and is highly optimized, among other things, by a compiler, the structure of the target application, i. H. the final application in the vehicle to be included in the simulation process. For this purpose, the source code determined for the target architecture (the so-called target system or the target platform) of the distributed computing system is analyzed and broken down into a functional component and a component for determining the runtime behavior and annotated. These two components are translated for the test of the application and integrated into a so-called integration layer, which will be explained below, with appropriate configuration of a sequence control. In addition to calculating mapping rules, a high-precision estimation of the running times of a respective software component, as can be expected on the distributed computing system in the vehicle, takes place during the runtime of the test. The calculated times are then used for the appropriate synchronization of the different software applications and the verification of given performance requirements.

1 shows a schematic representation of the procedure used here. With R, E and W are calculation steps, so-called Ticks, shown on the test-computing system. The duration of a particular calculation step depends on the performance of the test computing system or a test computer. R indicates a read operation, E indicates a processing of one or more read data, W represents a write operation of data to a memory. A first software application P1 comprises by way of example three calculation steps, in each of which a processing of data follows. The reading of the data or data in the calculation step R should not be part of the first software application P1 in the example. A second software application P2 includes by way of example only two calculation steps in which data is processed, which are provided by the first software component P1. The calculation steps of the second software component P2 are followed, by way of example, as a final calculation step, by a write process W.

If the software component P1 were to be executed on a control unit of a vehicle, a time t _RS would be required for this purpose. However, since the simulation method is executed on a test computing system that is faster by a factor of 2 to 5 compared to the processor of the controller, the execution is already completed after a shorter compared to the time period t _TR . The execution times of the first software component P1 in the test computing system and a real control device thus differ by the time period Δt _real . This behavior of the controller on which the first software component P1 is to be executed is therefore taken into account in the simulation in the execution code. This means that the execution of the software component P1 is specifically delayed by Δt _real . In the embodiment shown in the figure, t _RS ends during the last calculation step E. It is therefore still necessary to wait a period of time t _P until the subsequent calculation step E can be carried out by the second software component P2. Compliance with this "pause" until the next calculation step is necessary to ensure the synchronicity of the software components P1, P2. The in 1 shown sequence is referred to as execution cycle MiC, which includes the execution of possibly multiple software components of a controller. The delay Δt _real may optionally be integrated in the execution code of a respective software component. The delay can also be determined during the execution of the software component.

The execution times of the annotated source code of a respective software component should take no more than twice as long compared to the original source code, which is almost identical to the much higher processor performance of the test computing system compared to the controller by the calculated during runtime synchronization Timing of simulation compared to the target system guaranteed.

In addition to an estimation of the runtimes by source code annotation, the execution time can be determined in a similar method on the basis of object code. This variant has the advantage that even protected software components can be analyzed according to the target system and, if appropriate, can be integrated into the test computing system via an emulator. In particular, this offers the possibility of third parties, such. As suppliers, in the development process of the application to involve.

2 shows the basic structure of a provided for performing the method test computing system TR. The software components to be simulated, which run on respective control units ECU1,..., ECU9, are distributed by way of example to three test computers TR1, TR2, TR3. In principle, a different number of test computers TR1, TR2, TR3 could also be used in a test computing system TR. The number of test computers used depends on the required computing power. As a test computer TR1, TR2, TR3 conventional computer, such. As PCs, which are used to increase their performance z. For example, you may have special acceleration hardware (such as graphics cards). The test computing system is preferably designed as a computer cluster. In principle, other hardware solutions can be used to provide the computing power. In such a computing cluster, new hardware technologies can be easily integrated.

In the exemplary embodiment, three control units are simulated by way of example in each of the test computers TR1, TR2, TR3, namely ECU1, ECU2, ECU3 in the test computer TR1, ECU7, ECU8, ECU9 in the test computer TR2 and ECU4, ECU5, ECU6 in the test computer TR3. The control units simulated in a respective test computer TR1, TR2, TR3 are each connected to one another via communication links KV. The communication links KV used in the real distributed computing system e.g. B. are formed by bus lines and the like, are simulated for simulation by a corresponding software component. The communication between the test computers TR1, TR2, TR3 is z. B. realized by a high-speed LAN. This comprises corresponding communication links KV, which are connected to a communication system KS. The hardware of the test computers TR1, TR2, TR3 is chosen many times over the performance of the target system to be protected. In this way, it is ensured that in addition to monitoring the simulation necessary software extensions are executable, the simulation is still done in real time.

In practice, each control unit ECU1,..., ECU9 may comprise any number of software components. Each control unit is logically organized as a partition with a defined memory and time allocation of the respective test computer. A partition represents in the test computer a virtual area in which the software components are executable. A test computer can have a plurality of such partitions. Each partition is guaranteed a certain amount of memory as well as a certain amount of processor availability. The partitions encapsulate the application under test from the simulation infrastructure, i. H. the test computing system. By this methodology, it is possible to expand the test computing system TR arbitrarily. The partitions can be distributed independently on the test computers and offer, in addition to the real image of a control unit in the simulation, the possibility of directly simulating and testing partitions as they are provided as part of the software architecture on the target system.

The test computing system allows automatic import of the test configurations. In addition, through the test computing system, hardware characteristics of the target system (i.e., the target processor and the target architecture) can be faithfully mapped. A performance-optimized parameterized approach dynamically integrates configuration data sets and software components into the test computing system.

The realization of the test computing system TR is based on the use of a so-called integration layer (integration layer), which is ideally also used on the target system. The embodiment of an integration layer is in 3 shown. In a partition which simulates the functionality of a control unit ECU, a number of software components are executed. In the exemplary embodiment, these are four software components SWK1, SWK2, SWK3, SWK4. Via an interface IF, the software components SWK1, SWK2, SWK3, SWK4 are controlled with respect to their timing. For this purpose, timing data T are made available via the interface IF. Another component of the integration layer is a sequence controller SCH, which configuration data KD are made available with which the interaction of the software components SWK1, SWK2, SWK3, SWK4 and possibly other software components in other partitions is determined. Via a port PT, data with other partitions on the same or another test computer on the in 2 exchanged communication network described.

The process control uses the configuration data to determine when which software component is executed. For example, stored in the configuration data, at which time the software component 2 requires data from software component 1. In this case, a sequence in the course of the software components must be adhered to in order to maintain the intended functionality.

Because the test machine where the partition is set up performs better than that has later real controller, the configuration data can be changed during a simulation on a task running in the background. As a result, however, the runtime behavior of the application or the individual software components SWK1, SWK2, SWK3, SWK4 to each other is not changed.

As the operating system of the test computer is preferably a real-time Linux, such. For example, Xefloral, which, in addition to emulating operating system functions of the target system's control system operating system, provides a wide range of development tools available to the application developer and administrator. The integration layer starts above the operating system level and provides a real-time software architecture for integrating the software components. The state-dependent control as well as the interfaces can be configured dynamically and represent standard software components.

The individual control units are logically represented by a group of operating system tasks with a defined scheduling in which the applications run. The communication between the operating system tasks takes place either locally (that is, via the main memory) or via the communication connections, such. B. broadband Ethernet connections. The dynamic configuration option is preferred over a so-called static binding of the software components due to the expected in a distributed development process, including with external partners, load and asynchronicity of the simulation processes.

4 shows the timing of networked operating system tasks or ECUs ECU1, ECU2, ..., ECUn. For each of the illustrated control units ECU1,..., ECUn, at least one execution cycle MiC is illustrated, which, as already explained, comprises reading R as the first calculation step, several execution / processing steps E, and writing W as the last calculation step. Out 4 It can readily be seen that the calculation steps R of a respective control device ECU1,..., ECUn are offset from one another by one calculation step in each case. In addition, the communication is shown on a communication link BUS, via which three messages N can be transmitted within a respective calculation step (ticks). This is because, for example, the ECU ECU2 has to process data detected by the ECU ECU1 in a previous execution cycle, etc. The communication is performed by a respective writing step W of a respective ECU ECU1, ECU2,..., ECUn caused.

5 shows the organization of the software components that are controlled via alternative flowcharts by means of different configuration data. A configuration record KD determines what the order and runtime is in the execution of the software components. The configuration data KD can be loaded parallel to the simulation and activated in real time in a kind of warm start. While the simulation of the software components takes place in an active task or main task MT, the loading of new or changed configuration data (identified by RecKD) takes place in a background task BT, which can be executed in parallel to the main task MT.

In 5 In the exemplary embodiment, temporally successive execution cycles MiC1,..., MiCn are shown, which are components of a first test configuration MaC1. This is followed by an execution cycle MiC1 of a second test configuration MaC2. Each of the execution cycles MiC1,..., MiCn comprises, as calculation steps, read R, execute / process E and write W. It is understood that in each execution cycle MiC1,..., MiCn also have a different number according to the respective software component respective calculation steps R, E, W could be executed. While the execution cycles MiC1,..., MiCn of the execution cycle MaC1 of the first test configuration are executed in the main task MT, a new configuration data record (RecKD) is loaded in parallel in a background task BT, which is used to execute the second test configuration MaC2.

Immediately after the completion of the first test configuration MaC1, the execution of the second test configuration MaC2 can begin. For example, in the context of the second test configuration, the behavior of the application with other software components can be checked in comparison to the first test configuration. In this case, it is possible for the software components of the second test configuration to resort to calculation results that are determined and provided by software components of the first test configurations. The method makes it possible to perform the simulation of an application without interruption, even with different test configurations. This is relevant, for example, when testing an application for a complete vehicle, in which it is to be checked how the application behaves with different motor controls, which are implemented by different software components. In addition to the actual application, test drivers and test monitors can be used for technical monitoring of requirements the test computing system to be involved. Test drivers and test monitors can be used to simulate the application. Likewise, these serve for Verification of behavior for compliance with previously modeled requirements or expected test results.

The test computing system and the method used in addition to classical module tests master the challenge of simultaneously testing non-functional as well as cross-part functional requirements. Non-functional requirements are, for example, redundancy, memory requirements, processor / bus utilization, response times, robustness, modularizability, etc. The hardware-related design of the test computing system during parameterization offers the advantage of automatically converting or configuring the application for the target system, the differences between Test configuration and target configuration, ie the configuration on the target system by using standardized software components and / or architectures as well as the integration of optimized serial software parts, to minimize testing. The test effort is thus largely shifted from the target system to the test computing system.

In contrast to the in-vehicle integration process, which is designed as a time-scaling configuration, validation, and approval process with the number of components, the test computing system can continually run, including multiple test configurations. H. 24 hours a day, seven days a week, in parallel with increasingly powerful processors, the integration of the entire system is future-proof virtually before the actual vehicle integration takes place, whereby the increasing software complexity can be counteracted.

The methodological approach for realizing the procedure according to the invention is as follows:
The basis for this is textually recorded, functional requirements. These are continuously checked for their consistency after formalization. This is done by corresponding, requirement-related test functions or so-called formal methods. The sum of all validated requirements describes the solution space available for a model-based function design. The functions are developed modularly as partial solutions of a functional overall system taking into account the technical requirements for the description of imaging regulations, status description and transaction behavior.

Partial solutions are verified in a system verification process against their directly assigned requirements. It checks whether it is permissible, d. H. requirement-compliant solutions. One method of system verification, in addition to the so-called "model checking", is the generation of formal requirements from the solution described by models. The set of requirements thus generated describes the solution equivalent to the model. If the technical set of requirements is checked for consistency in pairs with the functional requirements from which the solution was developed, then there is a very good criterion for the solution conformity. The criterion is necessary but not sufficient. In the case of contradictions between solution and requirement, not only weaknesses in the solution may also be derived directly from requirements adjustments. The consistency of the requirements then ensures an adequate change management process.

The verified partial solutions are integrated in a follow-up model-based model to form a complete solution. Integration tests check the overall system for a violation of non-functional requirements as well as a subsystem or component-functional requirements. The procedure consists of the three steps of plausibilizing the requirements, verifying the partial solutions on a model level and integrating the partial solutions through testing.

This procedure lies in the 6 underlying infrastructure. A front end 602 is used for data entry, such. B. in the requirements development and modeling of the partial solutions. Data is stored in a suitable data management system 606 managed consistently, being beyond the front-end 602 on the in the data management system 606 stored data can be accessed. From the front end 602 All necessary configuration data, which in the figure as considered information or parameters 608 are shown, the test computing system, by a back-end 604 is represented, rejected and made available to it.

The plausibility of the requirements can be carried out incrementally. When new requirements are added, the plausibility is automatically checked as a "consistency check". If the requirements are structured and the partial solutions contain only a few requirements, this task can be carried out directly in a development tool. For reasons of maintainability and scalability, the individual checks are preferably carried out in parallel on the backend designed as a computation cluster with the aid of high-performance computing units. The result is finally transferred to the model-based development tool in the front-end.

The verification of largely independently developed partial solutions is carried out by formal methods or the known per se model Checking. The prerequisite for this is a modularization of the partial solutions due to the high memory requirements of a Model Checker. The algorithms or software components are carried out concurrently on the back-end in the batch processing mode or as a so-called legacy software component in an in 4 integrated electrical / electronic system platform integrated.

In the architecture of the test computing system TR is a virtual hedge 702 intended. It communicates in real time with the electrical / electronic system platform 704 , Via standardized interfaces 706 can test and application software components 708 , Functions 710 and legacy software components 712 into the system platform 704 be involved. The system is characterized by the fact that it can be extended by individual modules by adding additional interfaces 714 to the system platform 704 be provided.

The invention is characterized in that the simulation of distributed computing systems can take place in real time. A hardware-independent infrastructure allows the integration and protection of system components already at a very early stage, before the real computing units, z. As control devices in a vehicle, already exist. The computing power to perform the simulation can be provided inexpensively with conventional computing systems. By means of configuration data sets corresponding to the hardware to be simulated, the simulation can be calibrated. Furthermore, the integration of subsystems can virtually be tested in advance of the implementation in the distributed computing system, whereby real integration tests need not take place or take place to a lesser extent. Easy replacement or expansion of test computers in the test computing system ensures good scalability and cost-effective maintenance. The method makes it possible to estimate the time of target system-optimized software components precisely and with high performance. In addition, the method is characterized by the fact that real hardware can be incorporated as peripherals due to the real-time capability according to a HIL.

LIST OF REFERENCE NUMBERS

P1

first software component

P2

second software component

R

Calculation step: Read

e

Calculation step: Execute / Process

W

Calculation step: Write

MiC

Execution cycle of a software component

Mic1

Execution cycle of a first software component

MICN

Execution cycle of an nth software component

MaC

Execution cycle of a test configuration

MAC1

first test configuration

MAc2

second test configuration

t _TR

Execution time of a calculation step (tick) on the test computer system

t _RS

Execution time of a calculation step (tick) on a computing unit of a real computing system

t _p

Time buffer until the beginning of the next calculation step (tick)

Δt _real

Time difference of the execution times on the test computing system and the computing unit of the real computing system

ECU

simulated arithmetic unit of the real computing system in the test computing system

ECU1

simulated arithmetic unit of the real computing system in the test computing system

...

ECU9

simulated arithmetic unit of the real computing system in the test computing system

KV

communication link

KS

communication system

SWK1

Software component

SWK2

Software component

SWK3

Software component

SWK4

Software component

KD

configuration data

SCH

flow control

IF

interface

T

Timing data

PT

port

BUS

communication link

N

message

MT

active task (main task)

BT

Background task

RecKD

changed configuration record

C1

cycle

cn

cycle

Cn + 1

cycle

TR

Test computing system

TR1

test computer

TR2

test computer

TR3

test computer

602

Front End

604

Back-End

606

Data Management System

608

considered information / parameters

702

virtual protection

704

E / E system platform

706

interface

708

Software component

710

function

712

Legacy software component

714

interface

Claims (13)

Method for testing an application that is intended for execution in a distributed computing system, in particular a vehicle, having a number of computing units (ECU1,..., ECU9) connected via a communication network, wherein the application consists of a plurality of software components (SWK1, ..., SWK4) is formed with a respective functionality, which are provided for their execution on the computing units (ECU1, ..., ECU9) of the computing system, in which At least some of the software components (SWK1, ..., SWK4) of the application as a test configuration (MaC1, MaC2) are executed simultaneously on a test computing system (TR), whereby in the execution of a respective software Component (SWK1, ..., SWK4) whose temporal behavior on the arithmetic unit (ECU1, ..., ECU9), on which the software component is to be executed, is taken into account by the expected in the distributed computing system temporal behavior of the application to simulate, and - the behavior of the application is evaluated. The method of claim 1, wherein the execution code of a respective software component comprises a functional portion comprising the structure of the software component for execution on the real computing unit, and a portion for determining the runtime behavior on the real computing unit. The method of claim 1 or 2, wherein in the execution code of a respective software component, the temporal behavior of the computing unit on which the software component is to be executed, is integrated, Method according to one of the preceding claims, wherein the temporal behavior of the arithmetic unit, on which the software component is to be executed, during the execution of the software component is determined. Method according to one of the preceding claims, wherein the test computing system is operated with a real-time operating system. The method of claim 5, wherein the real-time operating system emulates the operating system of a respective computing unit. Method according to one of the preceding claims, in which the functionality of a respective computing unit is provided logically by a task with predetermined timing (scheduling), in which one or more software components are executed. Method according to one of the preceding claims, wherein the test computing system comprises a number of test computers, which are connected in the case of multiple test computers via a communication system, wherein one or more tasks are performed on a respective test computer. Method according to one of the preceding claims, in which the temporal behavior of a communication path of the computer system, via which two software components exchange data during the execution of the application, is simulated as an independent software module and simulated in the test on the test computer system. Method according to one of the preceding claims, in which a dynamic integration of a respective software component and / or a software module in the test configuration of the test computing system takes place, whereby different application scopes of the application can be checked. Method according to one of the preceding claims, wherein for a respective test configuration, a configuration data set is created, with which the order and maturity of the software components of a respective test configuration are determined, the configuration data set is processed by a flow control of the test computing system. The method of claim 11, wherein the configuration record is changed at runtime of the test. Method according to one of the preceding claims, in which a means for technical monitoring of predetermined requirements is integrated into the test environment.

Images