WO2006081869A1 - Vorrichtung und verfahren zum testen von komponenten und systemen - Google Patents

Vorrichtung und verfahren zum testen von komponenten und systemen Download PDF

Info

Publication number
WO2006081869A1
WO2006081869A1 PCT/EP2005/014087 EP2005014087W WO2006081869A1 WO 2006081869 A1 WO2006081869 A1 WO 2006081869A1 EP 2005014087 W EP2005014087 W EP 2005014087W WO 2006081869 A1 WO2006081869 A1 WO 2006081869A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
configuration
module
components
systems
Prior art date
Application number
PCT/EP2005/014087
Other languages
English (en)
French (fr)
Inventor
Rainer Casdorff
Maan Al-Homci
Jan Bobolecki
Josef Kruse
Dirk Martinen
Klemens Brumm
Original Assignee
Airbus Deutschland 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 Airbus Deutschland Gmbh filed Critical Airbus Deutschland Gmbh
Publication of WO2006081869A1 publication Critical patent/WO2006081869A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers

Definitions

  • the invention relates to a method for testing components and systems, in particular in the development and integration of aircraft systems.
  • test procedures with technical systems in industry, specifications are checked, test results are evaluated and evaluated.
  • test results are evaluated and evaluated.
  • the o.g. Method also for a variety of other areas such. in general for research and development, pharmaceutical industry / chemistry, mechanical engineering, electrical industry / electronics etc.
  • test engineer had to set essential test conditions for himself: Depending on his experience, he grouped test parameters and testable units; in the boundary conditions, it was left to his discretion, how the artificially created environment (eg simulation of flight conditions) procured or how the data transfer should be formed. The probability was that then the test quality depended strongly on the qualification of the respective test engineer, ie the results could vary even though the same test conditions existed. In contrast, newer test methods are largely automated and improved in this respect, ie subjective influenceability is minimized.
  • test In current and established automatic / semi-automatic test methods, the test is performed as a validation or verification of test components.
  • the test as such is out of its context, i. isolated from the overall process. As most system components today are more complex and complicated, it is not enough to name and test the system requirements, but they need to be managed, tracked, modeled, and checked for consistency.
  • US 5 023 791 proposes an automatic testing device for aircraft control, the test control unit (controller) having several functions, i.a. programmed instructions (e.g., test sequences) and flight test data are stored. Two additional SUTs are used (SUT redundant) to generate redundant signals.
  • SUT redundant Two additional SUTs are used (SUT redundant) to generate redundant signals.
  • a disadvantage of this tetstone direction is that a separate driver has to be created for each specific test case. This is then valid exclusively for this test case and can not be used elsewhere.
  • the driver is a software interface between the test script and the hardware (device under test). If the test case is changed, the driver must also be adapted.
  • the driver is only designed for a specific bus and can communicate with another bus by changing it. Furthermore, in the aforementioned document no system requirements, i.
  • Parameters that describe the behavior and function of a test object under different conditions can be integrated. Also, each type of interface requires a special implementation (driver) to connect the controller to the bus. In addition, the expression of the physical parameters on certain interfaces (signals) is not part of the test process and only one test object (UUT) can be tested at a time.
  • US 6,128,759 relates essentially to firmly defined systems and individual fixed models.
  • the model is only responsible for the test of a specific UUT or SUT.
  • the model is always based on the UUT and must accordingly changed and adjusted when another or new UUT is being tested.
  • Further limitations in the above script relate to the characteristics that concurrent testing and simulation is not possible, that all interfaces must be pre-defined, and that a change of direction requires a redesign of the sender / receiver.
  • an interface must be known per signal type. Thus, a test case is only suitable for this one special interface.
  • switch matrix For example, several bus systems can not be supported by reconfiguring the software.
  • switch matrix For example, several bus systems can not be supported by reconfiguring the software.
  • test procedure has the necessary flexibility and dynamic adaptation in view of the continuing complexity of future systems as a result of the aircraft operators' extended demands on the systems to be provided with regard to configuration and system architecture.
  • An essential advantage of the invention lies in the complete traceability of the system requirements and their modeling, wherein these systemrequirements are testable in different simulated environments.
  • Another significant advantage of the invention is the ability to perform cross-system testing.
  • tests during operation can also be included in the test process. This is particularly important for testing in the aerospace sector, as during a test cycle (taxiing at start, climb and cruise, descent, landing) a variety of influencing parameters act, so that tests on the ground and in the air in the test process are taken into account.
  • the flight-specific requirements are particularly important, as are the tests derived from them.
  • the cabin requirements eg air conditioning, passenger information system, toilets, seats, etc.
  • test procedures it is achieved according to the invention that the components in test operation can be identified, all operating conditions are monitored and the respective operating configuration (status) is displayed.
  • Such tests which measure behavior, functionality, and properties under a variety of conditions, can result in as many as 5,000 to 10,000 or more factors in a single modern aircraft system. It is clear that such a number of parameters can only be processed automatically.
  • a state characterizes an object and is completely described by its state variables.
  • a component is a hardware element or software element with at least one function.
  • the component is in a state that may be affected by environmental state quantities and is described by component state quantities. Examples are:
  • a function is a desired technical effect or a desired state.
  • a system is an assembly of components with at least one system function achieved by the components in interaction.
  • the system is in a state that may be affected by environmental state quantities, influenced by component state variables, and described by system state quantities.
  • a component requirement is a specific requirement for a component to reach certain component state quantities. Specifically, here means that the component requirement is tailored to a respective component and, conversely, the component is designed for the component requirement.
  • a Systemrequirement is a specific requirement for a system to reach certain system state sizes. Specifically, here, the system requirement is tailored to a particular system, and conversely, the system is designed for system demand.
  • a test component is a hardware test element or software test element for forming a test system.
  • the test element may have functions of various types, such as providing an environment in which a component is tested, simulating an environment by providing simulated environmental state quantities in the form of signals as input to a component in the test, ie a UUT, detecting a state quantity, by taking a value, measuring or calculating.
  • a UUT in one test may be a test component in another test.
  • test system consists of all the test components necessary for a test.
  • a test arrangement is an arrangement with a test system and a UUT, ie a component or a system.
  • test system request is a specific requirement for a test system to test certain system states or system state variables.
  • the test system requirement is tailored to a particular system.
  • the test system requirements can be geared to compliance with the component or system requirements or, on the other hand, the behavior of the components or of the system in the event of an unusual environmental condition. For example, the testability of a defined brief power interruption is a requirement of the test system.
  • testrequirement is the implementation of a component or systemrequirement in a test system to test this component or systemrequirement.
  • the test requirements can be identical with component or system requirements or, on the other hand, implement component or system requirements in qualifiable and quantifiable quantities. For example, the response behavior of the components or of the system to a particular environmental condition, such as a defined short-term power interruption, in Parmeter or Limits feasible.
  • the system requirement "the system should be able to work after a momentary power interruption” can be converted into a test system request "the test system must be able to perform a short voltage interruption of 0.5 s at the UUT”, and on the other hand to a first test request "the processor of the UUT must reboot itself at a short-term power interruption of 0.5 s "and a second test request” the processor of the UUT must be ready for operation within 20s after a new boot. "
  • a complete test includes test planning, test design, test case generation (TestCases), test procedure, test execution, and test evaluation.
  • Test planning is the creation of a test plan that defines the properties to be tested.
  • Test Design contains the definition of the test components used in the test.
  • Test cases are defined scenarios that each determine an initial situation in a test.
  • Test procedure is the definition of test steps.
  • a test step may have functions of various types, such as providing an environment in which a component is tested, simulating an environment by providing simulated environmental state quantities in the form of signals as input to a component in the test, ie detecting a UUT, detecting a state variable one value, measure or calculate, or several of these simultaneously. Test steps can be consecutive or parallel to each other.
  • the test procedure is planned before execution and executed during execution.
  • Test execution is the execution of the test procedure, usually in real time. During the test procedure test data are obtained.
  • Test evaluation is the evaluation of the test data obtained during the test procedure.
  • Reproducibility is the property, in particular of a test or a phenomenon, to obtain the same result when repeated under the same starting conditions.
  • Traceability is the ability to track the effect of changing an environmental state variable during a test run.
  • Traceability through a test process is the ability to track the effect of a change in an element, an environmental state quantity or a test component, during a development project.
  • Traceability via a test process preferably includes traceability of versions of a component during deployment of the component in an evolutionarily enhanced system.
  • the traceability via a test process preferably contains a possibility of determining all elements in which a particular system request or a specific signal occurs. Versions with changes in the definitions, both the environment variables and the UUT, should be traceable via various test executions, such as system requirements, eg when a key is pressed, a door should open within 5 s; or about signals, eg open_door.time ⁇ 5 s.
  • Test process is an evolutionary development of a complete test in a development project in which a UUT evolutionarily evolves.
  • the evolutionary evolution of the UUT includes both the specification of the UUT, the definition of the environment of the UUT, and the selection of the component or components of the UUT.
  • Compiling involves the steps of - reading (parsing) data from the UUT, - logically linking it to the hardware of the test component (s) or the test system, and - creating a configuration of the test item.
  • Configuration of the teststem is the definition of the connection of the test component (s) or of the test system with the data of the UUT.
  • Verification is an examination of a UUT for functionality.
  • Validation is validation of whether all data elements of a UUT are formally described and consistent. In a complete test, different levels of bias take place before the test is carried out.
  • Software validation is for a software to check the input for accuracy and is not to be confused with the validation in the context test.
  • Test cycle involves a special test consisting of taxiing at take-off, climb and cruise, descent, landing,
  • the management of the system test entails that the entire system requirements of all systems in one place are preferably collected centrally and made available to the entire testing process. This serves both traceability during a test procedure and traceability via a test process.
  • the system captures all its components.
  • Modeling defines the development of test procedures for individual or groups of component or system requirements. The result of this development is referred to below as a test request. The exact procedure is described in the test design. The basic idea in modeling is the meaningful mapping of systemrequirements to testrequirements.
  • a simulated environment comprises the following elements:
  • Operational configuration is understood to mean the provision of data information that the SUT needs during test operation.
  • the generation of such an operating configuration is part of the work in the generation of test cases;
  • the status of this configuration should also be documented.
  • the monitoring of this state should now be ensured by the validity ranges can be set, continuously checked and dynamically synchronized so that each operating state can be clearly assigned to the correct operating configuration.
  • test method according to the invention should provide the following services or have properties:
  • a function consists of at least one function module which is supplemented with the tester criterion "PASS" or "FAIL” during the test implementation. Upon completion of the test execution, this test criterion is set, so that it is immediately visible which functionality or which function block is affected by errors. On the other hand, what has been successfully tested becomes visible in this context. The more precisely the function blocks are defined, the more accurate is the error analysis.
  • the function-oriented test implementation with a modular test set-up of function test blocks as building blocks of the test system facilitates the maintenance of an incorrectly implemented function test by modifying a single function test block so that all affected tests automatically use the corrected version.
  • a function is tested by testing all its function blocks sequentially or simultaneously.
  • a test case is implemented.
  • the grouping of the test cases maps the tests in the form of a test procedure, i. A test case may be involved in one or more tests.
  • the modification of the test case causes a modification of all tests in which the test case is involved; this also cross-aircraft.
  • the user of the test system according to the invention will always be able to document the actions carried out and thereby ensure quality assurance.
  • FIG. 6 shows a test arrangement for testing components and systems, in which the elements from FIG. 4 are divided according to test system components
  • Fig. 8 embodiment of the method comprises the step preparing a test
  • FIG. 11 shows an embodiment of the method for integration of the system request
  • Fig. 13 embodiment of the method for integrating a signal translation.
  • FIG. 1 shows the mapping of the logical values onto physical values (signal & mapping) in the method according to the invention
  • the generic driver (4.14, see also FIG. 4 -> elements 4.13-4.20) assuming the task of the physical parameters (1.1) (eg temperature and pressure values) automatically assigned to the corresponding bus (1.3) (mapping). They are assigned a logical value (4.14 mapping: logical 1/2/3), i. a physical value can have different logical designations (signal) for different buses (1.3: Bus 1, Bus 2, Bus 3, ).
  • the mapping of each physical value is done by generic drivers (4.14) so that each physical parameter (1.1) can have one or more logical views;
  • a signal position is assigned on the bus that corresponds to the real position in the aircraft.
  • the logical views are used by the driver and represent the expression of a physical parameter on a specific bus medium.
  • FIG. 2 shows the integration of UUT (2.2) with its environment (2.3), which UUT can be integrated into any real environment, which expresses that the control unit according to the invention is capable of receiving and transmitting Observe signals from the SUT or the UUT (2.1).
  • the test system according to the invention uses a generic driver (signal configuration, integrated in 4.14 configurable test engine) in contrast to the known solutions with fixed drivers described above.
  • the method according to the invention with a generic approach means that the surroundings of the test object (2.3) are tested by means of signal generators (2.1 here: transducers, sensors, sensors, etc.). Initially, not the test item (UUT) (or the SUT) is tested, but the test system, namely whether the transmitted signals are evaluated correctly.
  • the test system according to the invention creates a specific environment by simulation (2.6) in the configurable test engine. This results in that in the test system in the test of a UUT (2.2) signals (2.8 and 2.7) (by the software solution of the generic driver) both received and sent (2.7 and 2.8) and can also be evaluated (2.1). In the above text such a reversible direction of transmitter and receiver is not possible. There, the inversion of transmitter / receiver would require a rebuild of the test stand and an additional test case, which is avoided in the test system according to the invention.
  • Fig. 3 indicates the manner in which the traceability is achieved via a test process in the test system according to the invention. Since systemrequirements (3.1) always form a unit with their UUT (2.2) (symbolized by SysReq's workflow), but the test system (2.5) according to the invention is able to integrate the UUT into different environments (2.5 workstations), systemrequirements (3.1 ), UUT (2.2) and test environment (2.6) are merged in one test. Thus, the system requirements (3.1) and the UUT (2.2) are not only tested and evaluated in a test environment (2.6), but in different test environments. That Similar tests take place under different conditions, which also correspond to the real aircraft configuration and enable a modeling of the system requirements.
  • the illustrated flowchart states that the modeling of the systemrequirements, and thus the testrequirements (integrated in a computer aided test generation assistant CATEGA 2.5), are tested on the basis of test cases (integrated in 3.2).
  • the procedure should be such that the modeling guarantees a high test coverage.
  • the picture elements 2.6, 3.4 and 2.2 show the process of generating and storing the operating configuration.
  • simulations are created using a simulator
  • test activities can be performed manually and automatically with clear interfaces between the processes (system development / implementation / test execution).
  • Test facility can consist of several components:
  • Parts, SUT All components or parts that are installed in a real aircraft, regardless of whether they represent the DUT or the test environment
  • SGR Software Ground Repository
  • Every valid complete configuration consists of:
  • test systems In order to be able to realize this procedure, the test systems must be set up in such a way (Test facility build-up) (4.5) that they correspond to the real specifications.
  • This method can link the test device (4.3) consisting of the SUT and / or test environment (2.2) for each test to be executed (4.28), and thus the test with the same environment can be repeated at a later time. This ensures that each test can be readjusted at any time in the right environment.
  • Process elements 4.6 and 4.7 Signals (4.14) are assigned to each test stand configuration (4.3) (see Signal translation) and thus the configured test stand (4.6) with its integrated signals is available to the scripts of the test cases (manual or automatic) (4.11). Since several test stand configurations can be created, a specific test stand configuration must be assigned to each test module (group of test cases) (4.12). This approach fully describes each test and provides a traceable, reproducible, recoverable and repeatable test overall configuration.
  • the process elements 4.6, 4.7, 4.11, 4.14 and 4.19 relate to traceability and traceability via a test process in test sequences according to the invention.
  • the test modules 4.6, 4.7, 4.11, 4.14 and 4.19 are assigned the operating configuration (4.3) in this step so that Systemrequirements (4.8) with their test environment (2.5) always form a specific version of a test.
  • the process elements 4.13 to 4.20 show the generic driver (4.14) that is used to integrate the UUT (2.2) into the test environment (3.7) (see Fig. 1). The following is a more detailed description of the processes (see also Fig.2).
  • test system (2.5) thus ensures harmonization, monitoring and documentation of the test process, in which all possible inputs and relevant influences of the test environment (4.3, 4.14) are integrated into one unit (4.6). Harmonization is ensured by integrating the system requirements (4.8) into the entire testing process.
  • the test process consists of the parts: test planning (4.9), test case determination (4.10), test case conversion into executable scripts (4.11), problem reporting (4.23), test execution reports (4.22) and verification of results (4.24).
  • the corresponding system requirements to be tested are known in the entire process modules (TEP 4.9, TD 4.10, TC 4.11, TP 4.12) and can therefore be used for each test case (4.11), test report (4.22), test execution (4.28) and test evaluation (4.24) are related to the corresponding system requirements (4.8).
  • test system is characterized by these signal translation modules (4.17, 4.18), wherein the signal translation is a process for automatically transforming formally defined interfaces (4.16), network structures (4.15) and bus definition (4.19) into executable scripts (4.14 ) respectively.
  • These executable scripts are used to automatically configure the test stand (4.6) so that it assumes the role of the real system.
  • the translation process (4.17, 4.18) is implemented in the test system according to the invention by an additional module.
  • the following points are realized with this module:
  • Signals (4.16) representing the physical parameters of the system are formalized (4.17) so that they can be read by software (4.14).
  • the hardware configuration relevant for the test stand (4.3) is read in to map the real interfaces to the test stand interfaces (4.6)
  • the signals are typed, depending on which bus they are sent (4.17)
  • the typed signals are then connected to the I / Os (inputs & outputs) (4.19) of the test stand and checked for correctness (4.20)
  • test rig When this configuration is loaded, the test rig is able to simulate, stimulate, and control the interfaces of the system.
  • several systems can be interconnected with this method (multi-system test). This ensures that all systems involved in the test communicate with each other through validated interfaces.
  • Network configuration (4.15): Formal (software evaluable) description of all elements involved in the network.
  • Signal description (4.16) Formal (software evaluable) description of the system interfaces (signals and PIN position).
  • a / C baseline (4.13): The management of the reference files of all interconnected systems is implemented here, so that the compatibility between the individual systems is ensured, for example, that version 1 of system A can only interact with version 2 of system B. but not with version 3 of system B, even if it is more up-to-date. For each test, all configurations must come from a specific baseline only.
  • test system In order for a test object (2.2) to be able to be automatically configured at all, the test system according to the invention must be composed of informal documents (specifications), formal scripts (in 4.1 1) or configurations (4.3). These automatically loadable scripts are linked with the real signals (4.14) and made known to the test process via SIB configuration (4.6) and are part of the test. Thus, the test system according to the invention is able to report at any time, with which configuration or form of the test specimen, has been tested:
  • Network Config. (4.15) and signal config. (4.16) are informal documents that are checked for correctness (4.18)
  • the previous process creates the signal configurations (4.14) that can be loaded automatically and map part of the SIB configuration (4.6). These correspond to the formal documents.
  • test scripts of the test cases (4.11) can be declared with the corresponding variables (signals), the signal configurations (4.14) created above are included in the test cases (4.7) and from which internal variables are defined that define the test progress (4.9-4.12 and 4.28 -4.24) so that a later evaluation, with respect to the A / C baseline (4.13), is possible.
  • Signal & Mapping (4.17): Signal description (4.16) displays all physical parameters depending on the media on which they are transmitted (4.15).
  • a signal represents the following:
  • Transmission medium TCP / IP connection (4.15) Transmission characteristics, eg. Frame rate, refresh rate, ...
  • testbench integration SIB Configuration
  • the purpose of this process is to provide the resource (4.3 software, hardware and configuration) with the interfaces (4.14 signals and mapping) so that external processes or applications can exchange data with the test setup (4.5 testbench).
  • This means that the test setup is modulated into an integrative unit with the ability to communicate with the environment.
  • the principle used so far is to define systems via their interfaces without having to know the contents, e.g. internal behavior / state of a system.
  • the test system according to the invention develops the interface definition (4.14) as a function of the internal properties of the system so that internal functionalities can also be stimulated or controlled by the external interfaces.
  • the former encapsulation of the system is canceled and the test system according to the invention thus achieves that the black-box principle is converted to a grey-box principle.
  • FIG. 5 shows how the method according to the invention is composed of the main individual modules:
  • test planning In the module "Test Execution-Plan” (4.9), ie the test planning, the complete test procedure (4.9 -5.18) is planned. Requirements (3.1 Systemrequirements), specifications, standards, tasks and conditions for the entire test are defined. Each individual process step during the test is specified and defined using resources (5.18 and 4.6), personnel, time and risk. With test planning (4.9) all objects to be tested (5.2 Test Items) are announced, together with the functions to be tested (5.3 Test Features) of each individual object. The functions (5.3) are the Systemrequirements (3.1) assigned accordingly. This provides the basis for the test strategy in this process step based on the test features.
  • Test Design (4.10) the specification of the test planning (4.9) takes place.
  • the test strategy (4.10, 5.5-5-7) (or several) is developed, defined and specified for the following tests (4.11).
  • test design levels (5.8), which can be multi-level. These levels determine the number of methods and functions to test.
  • Test objects are formed (5.5), which consist of one or more testrequirements (5.6).
  • test requirements are assigned the test features (5.3) specified in the test planning (4.9); different depending on the test strategy.
  • system requirements (3.1) are broken down into arbitrarily small steps (5.7 days).
  • each Testrequirement (5.6) can be tested with a different intensity (5.7 Depth).
  • test gases a UUT is tested in the test environment specified by the tester in the test design (4.10) (4.6, 5.18) and boundary conditions.
  • the individual test steps (4.12) are defined and the individual pass / fail criteria are specified.
  • a test gas it is now possible to check whether the testrequirements (5.6) created by the tester in the test environment (4.6, 5.18) correspond to the signals (5.16) from the real system world. This can optionally also be checked fully automatically.
  • the Test Design Document (4.28) developed in "Test Design” (4.10) is converted into executable test scripts (4.22), whereby several different script forms (4.22) are possible.
  • test cases (4.11) are summarized and prepared for test execution (5.11). Only one test procedure (4.12) can be assigned to a test execution (5.11) in which the test (5.9) is executed. Date and time are given, as well as which resources (4.6, 5.18) were tested. It is possible to create different configurations (4.6) of a test stand and assign them to a test execution (5.11). All steps performed are documented (partial aspect of the documentation).
  • test results (5.12) are presented.
  • Problem Reports (4.23) it is possible to specify problems of a test with its used resources and to send them to different places.
  • test In the module "Test Execution" (5.11), the test (5.9) defined in the test procedure (4.12) is connected to the resource (4.6 and 5.18) and a report is generated for the test execution (4.23 part of a test report). The test results (5.12) are then evaluated and error reports are generated (4.23 problem report) After completion of a test phase, all associated test execution reports and problem reports are compiled in a comprehensive report, the test report (4.24 Test reports). This is entered in a document version management system (4.24 and also Fig. 4 / 4.26).
  • the inventive method for testing components and systems ensures that the harmonization and documentation of the test process, in which all possible inputs and relevant influences of the test environment are integrated into one unit.
  • the characteristics break down as follows:
  • the harmonization is formed by merging the test environment by integrating resources (4.3), signal configuration (4.14), I / O description (4.19) and signals (4.7) into a test bench configuration (4.6). This harmonization is supplemented by a connection with a test module (4.12) and its test cases (4.11), which map the system requirements (4.8). The merging of the test environment with the system requirements is realized in the test execution (4.28).
  • Versioned system requirements are available for the test design (4.10); Marking changes to the system requirements (4.8) through new imports or modifications (new, edit, delete) as well as a change of status in Test design (4.10);
  • test system 2
  • Modular construction of the test system (2.5) according to the invention (i.e., clear interfaces between the modules);
  • Each defined module (4.8-4.12, 4.2, 4.3, 4.6, 4.28) can be connected multiple times and across all versions.
  • test items (4.1) are imported and formalized in the test system (2.5) according to the invention by the goods receipt module (4.2).
  • test setup software depot, 4.4
  • Other software elements relevant to the test setup are also imported and formalized.
  • the merging of all elements represents the overall configuration of the test and is versioned managed by the resource management module (4.3).
  • the module (4.3) is available for every test and is made known to the test process (4.28) via the SIB configuration (4.6).
  • the resource components (4.3) are versioned defined and also versioned linked to a test execution module (4.28).
  • the method according to the invention for testing components and systems advantageously has the further properties that a signal translation is integrated, with the following features and procedures:
  • the interface definitions are checked for consistency and correctness using Correctness check (4.18). In case of an error, a report and a change request are created using Failure report (4.20).
  • the input and output descriptions (4.19) are merged with the formalized data (correctness check, 4.18) via signal mapping (4.17) to form a signal configuration (4.14).
  • This generation or merging is displayed (status) in the SIB configuration (4.6) and saved.
  • the saved configurations form the basis for the test automation and are connected to the test case (4.11) via the CVS revision server (4.7); There exists a script generator, which connects the signals (from 4.7) and the test case (4.11) as input information to an automatically executable test.
  • test bench integration preferably has the further properties that the test bench integration can be implemented by means of the following methods:
  • test bench integration consists of merging the following modules:
  • test maintainability and expandability can be integrated by the following features:
  • Test cases (4.11) are designed generally valid and typified by the link to the SUT-dependent configuration of elements 4.6, 4.7. If the configuration changes from 4.6, 4.7, the test case remains valid because the adaptation is integrated in the configuration.
  • FIG. 6 shows a test arrangement for testing components and systems in which the elements of FIG. 4 are divided according to test system components.
  • a test arrangement for testing components and systems has a test system which has interfaces for connecting a Unit Under Test (UUT), a control unit for activating the test system, a database which stores data on component and / or systemrequirements of the UUT and data on a UUT Test has.
  • UUT Unit Under Test
  • control unit for activating the test system
  • database which stores data on component and / or systemrequirements of the UUT and data on a UUT Test has.
  • the test system for testing components and systems comprises the following test system components: a test preparation component (6.1) which receives as input a system specification, prepares this system specification for an implemented test instruction, and outputs this implemented test instruction; a test configuration component (6.2) receiving as input a baseline for an overall system configuration, rendering that baseline into a test configuration, and outputting that test configuration; a test execution component (6.3), which receives as input among other things the implemented test instruction and the test configuration, executes it and outputs the test result.
  • a test preparation component (6.1) which receives as input a system specification, prepares this system specification for an implemented test instruction, and outputs this implemented test instruction
  • a test configuration component (6.2) receiving as input a baseline for an overall system configuration, rendering that baseline into a test configuration, and outputting that test configuration
  • a test execution component (6.3), which receives as input among other things the implemented test instruction and the test configuration, executes it and outputs the test result.
  • test preparation component (6.1) is designed such that the implemented test instruction is always adapted to the system specification.
  • test configuration component (6.2) is configured such that the test configuration is always adapted to the overall system configuration.
  • a test arrangement according to the invention for testing components and systems preferably further comprises a device for assisting in the creation of a test procedure.
  • the means for assisting in creating a test procedure comprises a module for creating a test execution plan.
  • the means for assisting in the creation of a test procedure comprises a module for specifying the test arrangement and the UUT.
  • the means for assisting in creating a test procedure comprises a module for creating a test design.
  • the means for assisting in creating a test procedure comprises a module for creating test cases.
  • the means for assisting in creating a test procedure comprises a module for creating test scripts.
  • the means for assisting in creating a test procedure comprises a module for creating a test execution plan using the test cases.
  • the traceability of the input data and generated data through interface structure and data storage and data structure is explained by the following example.
  • the system specification contains system requirements 4.8 and system signals, eg voltage data.
  • the test preparation component 6.1 is designed such that the implemented test instruction is always adapted to the overall system configuration. For example, if the request data changes from ⁇ 5V to ⁇ 5.5V, the test implementation will be adjusted.
  • the test system according to the invention is a uniform system with defined interfaces between the components 6.1, 6.2 and 6.3 such that changes in the input data are automatically followed up and the tests are changed accordingly. Any components affected by the changes will automatically be marked as invalid until they have been retested to the modified specifications.
  • the test configuration component 6.2 is configured such that the test configuration is always adapted to the specification. For example, if a configuration data is changed "Bus 5, Message 1, Position 10" in Bus 5, Message 2, Position 10 ", the test configuration is automatically adjusted.
  • the test result contains a Test Execution Report and a Problem Report.
  • a method according to the invention for testing components and systems has, according to FIG. 7, the method steps:
  • Run 7.3 of the test wherein an implemented test instruction is always adapted to a system specification and the test configuration is always adapted to the overall system configuration.
  • the method step preparing a test comprises the sub-method steps:
  • the method step Preparing at least one test configuration has the sub-method steps:
  • the method step of carrying out the test comprises the sub-method steps: Loading 10.1 the test configuration;
  • the method preferably has a harmonization of the overall configuration and the specification.
  • the method preferably has a quality assurance of the input data by checking the overall configuration and the system specification.
  • the method preferably has a traceability of the input data and generated data.
  • the method advantageously makes it possible, on the basis of the method steps, to produce documentation for a particular time or period at any time.
  • the integration of the system request can be realized by means of the following features or process elements:
  • Flag 11.3 changes to system requirements 4.8 due to new imports or modifications New, edit, delete and display a change of status in test design 4.10;
  • a signal transmission is integrated, with the following features and procedures:
  • test serviceability and expandability can advantageously be integrated by the following features of the method:
  • Test cases 4.11 are designed generally valid and first typed by the link with the SUT-dependent configuration of elements 4.6, 4.7. If the configuration of 4.6 changes, 4.7 the test case remains valid, because the adaptation is integrated in the configuration;

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Ein Verfahren zum Testen von Komponenten und Systemen gewährleistet die Harmonisierung und Dokumentation des Testprozesses, in dem alle möglichen Eingänge und relevanten Einflüsse der Testumgebung zu einer Einheit integriert werden. Im einzelnen schlüsseln sich die Merkmale wie folgt auf: Harmonisierung: Die Harmonisierung wird einerseits durch die Zusammenführung der Testumgebung durch Integration von Ressourcen (4.3), Signalkonfiguration (4.14) , I/O-Beschreibung (4.19) und Signalen (4.7) zu einer Test bench Konfiguration (4.6) gebildet. Diese Harmonisierung wird ergänzt durch eine Verbindung mit einem Testmodul (4.12) und dessen Testfällen (4.11), die die Systemrequirements (4.8) abbilden. Die Zusammenführung der Testumgebung mit den Systemrequirements wird in der Test execution (4.28) realisiert. Qualitätssicherung gewährleistet durch Einzelprüfung der Zusammenführungen während der Harmonisierung auf Konsistenz und Validität, gewährleistet durch den Baustein Correctness check (4.18); diese Prüfung ist ebenso in den Modulen (4.8-4.12, 4.2, 4.3, 4.6, 4.28) integriert. Identifikation der Komponenten als klare Schnittstellen zwischen den Prozessen (Systementwicklung / Realisierung / Testdurchführung) gewährleistet durch die einzelnen erfindungsgemäßen spezifischen Module (4.8-4.12, 4.2, 4.3, 4.6, 4.28). Verfolgbarkeit über einen Testprozeß und Verfolgbarkeit durch Schnittstellenstrukturierung bestehend aus den Elementen (4.8-4.12, 4.2, 4.3, 4.6, 4.28). Dokumentation des Testprozesses mittels relevanter Modulen ausgestattet mit einem Reporting-Modul (4.20), der einen Bericht über den aktuellen Status, die Historie und alle Beziehungen des Moduls zu anderen Modulen als Dokumentation mit den Elementen (4.20, 4.21, 4.22, 4.26) erstellt.

Description

Vorrichtung und Verfahren zum Testen von Komponenten und Systemen
Die Erfindung betrifft ein Verfahren zum Testen von Komponenten und Systemen, insbesondere bei Entwicklung und Integration von Flugzeugsystemen.
Bei Testabläufen mit technischen Systemen in der Industrie werden Vorgaben überprüft, Testergebnisse ausgewertet und bewertet. Neben der Anwendung im Luftfahrtbereich bzw. Transportwesen kommt das o.g. Verfahren auch für eine Vielzahl anderer Gebiete infrage, wie z.B. ganz allgemein für Forschung und Entwicklung, Pharmaindustrie/Chemie, Maschinenbau, Elektroindustrie/Elektronik etc.
Die industriell hergestellten Produkte verfügen zunehmend über eine beachtliche Anzahl von Systemen, um die gewünschten Funktionen des Produkts erfüllen zu können, was durch Tests nachzuweisen ist. Diese Tests betreffen je nach Produkt unterschiedliche Bereiche bzw. Objekte: Software, Hardware, Komponenten, Funktionen, Einzelobjekte (Unit under test/UUT), Systeme (System under test/SUT).
In der Vergangenheit genügten manuelle Methoden, bei denen der Testingenieur direkt in den Testablauf eingegriffen hat. So mussten z.B.. verschiedene Bedienungshebel im Flugzeug verstellt, Testgeräte am Ort der zu prüfenden Komponente installiert als auch bedarfsweise die Flugzeugverkabelung unterbrochen werden. Schließlich wurden die verschiedenen Testdaten abgelesen und zur Dokumentation in Formulare eingetragen. Bei dieser manuellen Vorgangsweise bestand natürlich die Gefahr, dass sich Fehler einschlichen, zumal - wie oben erwähnt - in der Serienfertigung alle Einbaukomponenten im Zusammenwirken unter einer Vielzahl von Randbedingungen geprüft werden mussten. Zur Vermeidung von Fehlerquellen und um so auch Arbeitszeit, Personal und Kosten zu sparen, wurde im Laufe der Zeit der manuelle Testprozess automatisiert. Doch diese teilweise automatisierten Testverfahren wiesen immer noch eine Reihe von Nachteilen auf. So musste der Testingenieur wesentliche Test-Randbedingungen selbst festlegen: Je nach seiner Erfahrung gruppierte er Testparameter und testbare Einheiten; bei den Randbedingungen lag es in seinem Ermessen, wie die künstlich zu schaffende Umgebung (z.B. Simulation von Flugzuständen) beschaffen oder wie der Datentransfer ausgebildet sein sollte. Dabei bestand die Wahrscheinlichkeit, dass dann die Testqualität stark von der Qualifikation des jeweiligen Testingenieurs abhing, d.h. die Ergebnisse konnten variieren, obwohl die selben Testbedingungen bestanden. Demgegenüber sind neuere Testverfahren weitgehend automatisiert und in dieser Hinsicht verbessert, d.h. die subjektive Beeinfluss- barkeit ist minimiert.
In den aktuellen und etablierten automatischen / halbautomatischen Testmethoden wird der Test als eine Validierung oder Verifizierung von Testkomponenten durchgeführt. Der Test als solches ist aus seinem Kontext, d.h. aus dem Gesamtprozess isoliert. Da die meisten Systemkomponenten der heutigen Zeit komplexer und komplizierter sind, reicht es nicht aus, die Systemanforderungen zu benennen und testen, sondern diese müssen verwaltet, verfolgt, modelliert und nach ihrer Kohärenz geprüft werden.
In der US 5 023 791 wird eine automatische Testeinrichtung für die Flugzeugsteuerung vorgeschlagen, wobei die Test-Steuereinheit (Controller) mehrere Funktionen besitzt, u.a. werden programmierte Instruktionen (z.B.. Test-Abfolgen) und Flugtestdaten gespeichert. Es werden zwei zusätzliche SUTs verwendet (SUT redundant), um redundante Signale zu erzeugen. Ein Nachteil dieser Tetsteinrichtung ist, dass für jeden spezifischen Testfall ein eigener Treiber erstellt werden muss. Dieser ist dann ausschließlich für diesen Testfall gültig und kann nicht anderweitig eingesetzt werden. Als Treiber wird eine Software- Schnittstelle zwischen Testskript und Hardware (Prüfling) bezeichnet. Wird der Testfall geändert, so muss auch der Treiber angepasst werden. Der Treiber ist nur für einen speziellen Bus ausgelegt und kann durch Änderung mit einem anderen Bus kommunizieren. Weiterhin können in der vorgenannten Schrift keine Systemrequirements, d.h. Parameter die das Verhalten und die Funktion eines Testobjekts unter verschiedenen Bedingungen beschreiben, integriert werden. Auch ist pro Schnittstellentyp eine spezielle Implementierung (Treiber) erforderlich, um die Steuereinheit an den Bus anzuschließen. Außerdem ist die Ausprägung der physikalischen Parameter auf bestimmte Interfaces (Signale) nicht Teil des Testprozesses und es kann jeweils auch nur ein Prüfling (UUT) getestet werden .
Die US 6 128 759, bezieht sich im wesentlichen auf fest definierte Systeme und einzelne fixe Modelle. Dabei ist das Modell nur für den Test einer bestimmten UUT bzw. SUT zuständig. Somit orientiert sich das Modell immer an der UUT und muss dementsprechend geändert und angepasst werden, wenn ein anderes oder neues UUT getestet wird. Weitere Einschränkungen betreffen bei vorstehender Schrift die Eigenschaften, dass ein gleichzeitiges Testen und Simulieren nicht möglich ist, dass alle Schnittstellen vorher definiert sein müssen und dass eine Richtungsänderung Sender/Empfänger ein Redesign erfordert. Zudem zeigt sich bei o.g. Schrift, dass pro Signaltyp eine Schnittstelle bekannt sein muss. Demnach ist ein Testfall nur für diese eine spezielle Schnittstelle geeignet. Auch ist nur ein bestimmter Bus (fixe Verdrahtung) vorhanden, dargestellt durch das Objekt "Switch-Matrix"; dabei können z.B. mehrere Bussysteme nicht durch Umkonfigurieren der Software unterstützt werden. Zudem ist es nur möglich, ein einzelnes SUT in eine bestimmte vordefinierte Testumgebung zu versetzen.
Zusammenfassend ist festzustellen, dass die oben beschriebenen Beispiele sich mehr oder weniger auf spezielle Testabläufe beziehen, doch es wird in keiner Weise auf den gesamten Testprozess (Systemrequirements, Signale, Ressourcen und der damit verbundenen Konfigurationskontrolle usw.) eingegangen.
Somit ist es die Aufgabe der Erfindung, das automatische Testen komplexer Systeme zu verbessern.
Die Lösung der Aufgabe erfolgt durch die Merkmale der unabhängigen Ansprüche.
Erfindungsgemäß erfolgt eine umfassende Prüfung komplexer Systeme in ihrem Verbund - insbesondere bei Entwicklung und Produktion von Verkehrsflugzeugen. Damit wird das fehlerfreie Zusammenspiel der Systeme bereits vor dem Erstflug am Boden ermöglicht und nachweisbar. Zudem weist das Testverfahren im Hinblick auf die weiter fortschreitende Komplexität zukünftiger Systeme infolge der erweiterten Anforderungen der Flugzeugbetreiber an die vorzusehenden Systeme bezüglich Konfiguration und Systemarchitektur die dazu erforderliche Flexibilität und dynamische Anpassung auf.
Eine wesentlicher Vorteil der Erfindung liegt in der vollständigen Verfolg barkeit der Systemanforderungen und ihrer Modellierung, wobei diese Systemrequirements in verschiedenen simulierten Umgebungen testbar sind.
Eine weiterer wesentlicher Vorteil der Erfindung ist die Möglichkeit, systemübergreifende Tests durchzuführen. Neben Labortests können in den Testprozess auch Tests während des Betriebs mit einbezogen werden. Für die Tests im Luftfahrtbereich ist dies besonders bedeutsam, da während eines Testzyklus (Rollen am Start, Steig- und Reiseflug, Sinkflug, Landung) die verschiedensten Einflussparameter wirken, so dass Tests am Boden als auch in der Luft im Testprozess zu berücksichtigen sind. Beim Flugzeug sind die flugspezifischen Anforderungen (Flugleistung, Antrieb, Avionik, Sicherheit, Wartung etc.) besonders wichtig ebenso die hieraus abgeleiteten Tests. Daneben ist es für den Betriebserfolg aber Voraussetzung, dass auch die Kabinenanforderungen (z.B.. Klimatisierung, Passagier-Informationssystem, Toiletten, Sitze etc.) vollständig erfüllt werden. Somit obliegt es dem Hersteller für die Entwicklung und später für die Serienproduktion des Flugzeugs eine Vielzahl von Einzelkomponenten in der Flugzeugzelle zu integrieren und deren fehlerfreies Arbeiten unter den verschiedensten Bedingungen durch Tests nachzuweisen. Zwar sind die Einzelkomponenten bei Anlieferung auf Erfüllung ihrer Anforderungen von den Lieferanten überprüft worden, doch durch die Integration der Komponenten ins Flugzeug entsteht eine wesentliche komplexere Situation für den systemübergreifenden Prüfprozess.
Um die diversen Einbauelemente an die bordeigenen Energieträger wie Elektrik, Hydraulik und Pneumatik anzuschließen, werden nämlich eine Vielzahl von Kabeln, Leitungen, Stecker bzw. Schnittstellen-/Interface-Elemente benötigt, welche nach dem Zusammenbau als Gesamtes überprüft werden müssen. Dabei ist erschwerend, dass ggfs. auch nach Ausfall von Einzelkomponenten eines Systems eine gewisse Redundanz gefordert ist und dass andere Systeme unbeeinflusst bleiben. Hinzu kommt noch, dass in den Funktionstests verschiedene Flugzustände wie Geschwindigkeit, Flughöhe und Umgebungstemperatur berücksichtigt bzw. simuliert werden müssen. Außerdem wird dabei eine entsprechende Dokumentation der einzelnen Tests von Komponenten oder Systemen erstellt, die auch Bedingungen der Qualitätssicherung von Zulassungsbehörde und Hersteller genügt. Mit dieser Dokumentation ist eine umfassende Verfolg barkeit und Reproduzierbarkeit gegeben. Damit soll nicht nur die Flugsicherheit gewährleistet, sondern z.B. auch spätere Wartungsarbeiten und die Fehleranalyse erleichtert werden. Für die Testabläufe ist erfindungsgemäß erreicht, dass die im Testbetrieb befindlichen Komponenten identifizierbar sind, sämtliche Betriebszustände überwacht werden und die jeweilige Betriebskonfiguration (Status) angezeigt wird. Solche Tests, bei denen das Verhalten, Funktionalität und Eigenschaften unter verschiedenen Bedingungen geprüft werden, können schon bei einem einzigen modernen Flugzeugsystem zu 5000 bis 10.000 oder mehr Einflussgrößen führen. Es ist klar, dass eine derartige Anzahl von Parametern nur noch automatisiert abgearbeitet werden kann.
Nachfolgend einige bei der Beschreibung von Testabläufen verwendeten Begriffe.
Ein Zustand charakterisiert ein Objekt und wird vollständig beschrieben durch dessen Zustandsgrößen.
Eine Komponente ist ein Hardware Element oder Software Element mit mindestens einer Funktion. Die Komponente ist in einem Zustand, der von Umgebungszustandsgrößen beeinflusst werden kann und durch Komponentenzustandsgrößen beschrieben wird. Beispiele sind:
Eine Funktion ist eine angestrebte technische Wirkung bzw. ein angestrebter Zustand.
Ein System ist eine Anordnung von Komponenten mit mindestens einer System- Funktion, die von den Komponenten im Zusammenwirken erreicht wird. Das System ist in einem Zustand, der von Umgebungszustandsgrößen beeinflusst werden kann, von Komponentenzustandsgrößen beeinflusst wird, und durch Systemzustandsgrößen beschrieben wird.
Ein Komponentenrequirement (=Komponentenanforderung) ist eine spezifische Anforderung an eine Komponente, bestimmte Komponentenzustandsgrößen zu erreichen. Spezifisch bedeutet hier, dass das Komponentenrequirement auf eine jeweilige Komponente zugeschnitten ist und umgekehrt die Komponente auf das Komponentenrequirement hin ausgelegt ist.
Eine Systemrequirement (=Systemanforderung) ist eine spezifische Anforderung an ein System, bestimmte Systemzustandsgrößen zu erreichen. Spezifisch bedeutet hier, dass das Systemrequirement auf ein jeweiliges System zugeschnitten ist und umgekehrt das System auf das Systemrequirement hin ausgelegt ist.
Eine Testkomponente ist eine Hardware Test-Element oder Software Test-Element zur Bildung eines Testsystems. Das Test-Element kann Funktionen verschiedener Art haben, etwa eine Umgebung bereitstellen, in der eine Komponente getestet wird, eine Umgebung simulieren durch Bereitstellen von simulierten Umgebungszustandsgrößen in Form von Signalen als Eingabe für eine Komponente im Test, also einer UUT, eine Zustandsgröße erfassen, durch übernehmen eines Wertes, messen oder berechnen. Eine UUT in einem Test kann eine Testkomponente in einem anderen Test sein.
Ein Testsystem besteht aus allen zu einem Test notwendigen Testkomponenten.
Eine Testanordnung ist eine Anordnung mit einem Testsystem und einer UUT, also einer Komponente oder einem System.
Ein Testsystemrequirement (=Testsystemanforderung) ist eine spezifische Anforderung an ein Testsystem, bestimmte Systemzustände oder Systemzustandsgrößen zu testen. Spezifisch bedeutet hier, dass das Testsystemrequirement auf ein jeweiliges System zugeschnitten ist. Die Testsystemrequirements können einerseits auf die Einhaltung der Komponenten- oder Systemanforderungen abstellen oder andererseits das Verhalten der Komponenten oder des Systems bei einem ungewöhnlichen Umgebungszustand, beispielsweise ist die Prüfbarkeit einer definierten kurzzeitigen Spannungsunterbrechung eine Anforderung an das Testsystem.
Ein Testrequirement (=Testanforderung) ist die Umsetzung eines Komponenten- oder Systemrequirements in einem Testsystem, um dieses Komponenten- oder Systemrequirement zu testen. Die Testrequirements können einerseits mit Komponenten- oder Systemrequirements identisch sein oder andererseits Komponenten- oder Systemrequirements in qualifizierbare und quantifizierbare Größen umsetzen. Beispielsweise ist das Antwortverhalten der Komponenten oder des Systems auf einem bestimmten Umgebungszustand, etwa eine definierte kurzzeitige Spannungsunterbrechung, in Parmeter beziehungsweise Grenzwerte umsetzbar. Das Systemrequirement "das System soll nach einer kurzzeitigen Spannungsunterbrechung arbeitsfähig sein" kann umgesetzt werden einerseits in ein Testsystemrequirement "das Testsystem muß eine kurzzeitige Spannungsunterbrechung von 0,5 s an der UUT durchführen können", und andererseits in ein erstes Testrequirement "der Prozessor der UUT muß bei einer kurzzeitigen Spannungsunterbrechung von 0,5 s selbständig neu booten" und ein zweites Testrequirement "der Prozessor der UUT muß nach neuem Booten innerhalb 20s betriebsbereit sein."
Ein vollständiger Test umfaßt die Testplanung, das Testdesign, die Erzeugung von Testfällen (TestCases), den Testablauf (Test Procedure), die Testausführung und die Testauswertung.
Testplanung ist die Erstellung eines Testplans, der die Eigenschaften, die getestet werden sollen, definiert.
Testdesign enthält die Definition der Testkomponenten, die beim Test zum Einsatz kommen.
Testfälle (TestCases) sind definierte Szenarien, die jeweils eine Ausgangssituation bei einem Test bestimmen.
Testablauf (Test Procedure) ist die Definition von Testschritten. Ein Testschritt kann Funktionen verschiedener Art haben, etwa eine Umgebung bereitstellen, in der eine Komponente getestet wird, eine Umgebung simulieren durch Bereitstellen von simulierten Umgebungszustandsgrößen in Form von Signalen als Eingabe für eine Komponente im Test, also einer UUT, eine Zustandsgröße erfassen, durch übernehmen eines Wertes, messen oder berechnen, oder mehrere dieser gleichzeitig. Testschritte können nacheinander oder parallel zueinander stehen. Der Testablauf wird vor der Durchführung geplant und mit der Durchführung ausgeführt.
Testdurchführung = Testausführung ist die Durchführung des Testablaufs, üblicherweise in Echtzeit. Während der Testdurchführung werden Testdaten erhalten.
Testauswertung ist die Auswertung der während der Testdurchführung erhaltenen Testdaten.
Reproduzierbarkeit ist die Eigenschaft, insbesondere eines Tests oder eines Phänomens, bei Wiederholung unter denselben Ausgangsbedingungen das selbe Ergebnis zu erhalten.
Verfolgbarkeit während eines Testablaufs = Traceability ist die Möglichkeit, die Auswirkung einer Änderung einer Umgebungszustandsgröße während eines Testablaufs zu verfolgen.
Verfolgbarkeit über einen Testprozeß ist die Möglichkeit, die Auswirkung einer Änderung eines Elements, nämlich einer Umgebungszustandsgröße oder einer Testkomponente, während eines Entwicklungsprojekts zu verfolgen. Die Verfolgbarkeit über einen Testprozeß enthält vorzugsweise eine Verfolgbarkeit der Versionen einer Komponente während des Einsatzes der Komponente in einem evolutionär weiterentwickelten System. Die Verfolgbarkeit über einen Testprozeß enthält vorzugsweise eine Möglichkeit der Ermittlung aller Elemente, in denen ein bestimmtes Systemrequirement oder ein bestimmtes Signal vorkommt. Versionen mit Änderungen in den Definitionen, sowohl der Umgebungsvariablen als auch der UUT, sollen über verschiedene Testausführungen verfolgbar sein, etwa Systemrequirements, z.B. bei Druck auf eine Taste soll sich ene Tür innerhalb von 5 s öffnen; oder etwa Signale, z.B. open_door.time <5 s.
Testprozeß ist eine evolutionäre Entwicklung eines vollständigen Tests in einem Entwicklungsprojekt, in dem eine UUT evolutionär weiterentwickelt wird. Die evolutionäre Weiterentwicklung der UUT umfaßt sowohl die Spezifikation der UUT, die Definition der Umgebung der UUT als auch die Auswahl der Komponente oder Komponenten der UUT.
Kompilieren umfaßt die Schritte - Einlesen (Parsen) von Daten der UUT, - deren logisches Verknüpfen mit der Hardware der Testkomponente(n) bzw. des Testsystems und - Erstellen einer Konfiguration des Testsstems.
Konfiguration des Testsstems ist die Definition der Verknüpfung der Testkomponen- te(n) bzw. des Testsystems mit den Daten der UUT.
Verifikation ist eine Prüfung einer UUT auf eine Funktionalität.
Validierung ist Gültigkeitsprüfung, ob alle Datenelemente einer UUT formal beschrieben sind und konsistent sind. In einem vollständigen Test erfolgen vor der Testdurchführung unterschiedliche Valdierungsstufen.
Software Validation ist bei einer Software die Prüfung einer Eingabe auf Richtigkeit und ist nicht mit der Validierung im Kontext Test zu verwechseln.
Testzyklus betrifft einen besonderen Test, der besteht aus Rollen am Start, Steig- und Reiseflug, Sinkflug, Landung,
Die Verwaltung des Systemtests beinhaltet, dass die gesamten Systemanforderungen aller Systeme an einer Stelle vorzugsweise zentral gesammelt und dem gesamten Testprozess zur Verfügung gestellt werden. Dies dient sowohl der Verfolgbarkeit während eines Testablaufs als auch der Verfolgbarkeit über einen Testprozeß. Mit dem System sind alle seine Komponenten erfasst.
Als Modellierung wird die Entwicklung von Testvorgehensweisen für einzelne oder Gruppen von Komponenten- oder Systemrequirements definiert. Das Ergebnis dieser Entwicklung wird im Folgenden als Testrequirement bezeichnet. Die genaue Vorgehensweise wird im Test Design beschrieben. Der Grundgedanke bei der Modellierung ist die sinnvolle Abbildung von Systemrequirements auf Testrequirements.
"Kohärenz" bezeichnet die widerspruchsfreie (in sich geschlossene) Wechselwirkung von Parametern untereinander, die in einem ausführbaren Gesamtkontext bei der Entwicklung eines Testrequirements berücksichtigt werden muss. Diese Kohärenz zwischen Systemanforderungen mehrerer Systeme ist eine technische Realisierung, die bei den bekannten Testmethoden -d.h. dem Stand der Technik- nicht umgesetzt ist.
Dabei umfaßt eine simulierte Umgebung folgende Elemente:
Erzeugung einer Betriebskonfiguration,
Anzeige der Betriebskonfiguration (Status),
Überwachung von Betriebszuständen.
Unter Betriebskonfiguration wird die Bereitstellung von Dateninformationen verstanden, die das SUT während des Testbetriebs benötigt. Dabei ist die Erzeugung einer solchen Betriebskonfiguration Bestandteil der Arbeit bei der Generierung von Testfällen; zu einem definierten Zeitpunkt soll auch der Status dieser Konfiguration dokumentierbar sein. Weiterhin soll die Überwachung dieses Zustandes jetzt gewährleistet werden, indem die Gültigkeitsbereiche festgelegt, laufend geprüft und dynamisch synchronisiert werden können, so dass jeder Betriebszustand eindeutig der richtigen Betriebskonfiguration zugeordnet werden kann.
Aus vorstehender Bestandsaufnahme leiten sich im wesentlichen die relevanten Aufgaben bzw. einzelne Anforderungen an ein verbessertes Testverfahren ab. Hierbei soll das erfindungsgemäße Testverfahren die folgenden Leistungen erbringen bzw. Eigenschaften aufweisen:
Dokumentation
Reproduzierbarkeit / Wiederverwendbarkeit
Qualitätssicherung
Verfolg barkeit während eines Testablaufs / Verfolgbarkeit über einen Testprozeß
Testwartung erleichtern
Fehleranalyse erleichtern
Identifikation der Komponenten
Erzeugung, Anzeige (Status) und Speicherung der Betriebskonfiguration
Überwachung der Betriebszustände
Testautomatisierung
Das erfindungsgemäße Verfahren ist durch die folgenden Eigenschaften gekennzeichnet bzw. erfüllt die Kriterien:
Reproduzierbarkeit: Alle Systeme und Systemkomponenten werden entwicklungsbe- gleitend in verschiedenen aufeinander folgenden Entwicklungsphasen, vom Prototyp bis zum Endprodukt, getestet. Zu jeder Entwicklungsphase werden eine oder mehrere Funktionen getestet. In jeder neuen Phase kommen neue oder erweiterte Funktionen hinzu. Alle Tests werden funktionsorientiert und unabhängig voneinander implementiert, so dass die Funktionen einzeln oder in verschiedenem Zusammenspiel gestestet werden (Regressions- tests). Somit ist jeder Test für alle nachfolgenden Phasen wiederverwendbar. Alle Tests werden zusätzlich versioniert abgespeichert (ebenfalls wichtig für die Verfolgbarkeit über einen Testprozeß), wodurch zu jedem beliebigen Zeitpunkt ein Test wiederholt werden kann, unabhängig von der Entwicklungsphase.
Fehleranalyse erleichtern: Die Fehleranalyse wird dadurch erleichtert, dass Tests bis auf die kleinstmöglichen definierbaren Funktionsbausteine verfeinert werden. Eine Funktion besteht aus mindestens einem Funktionsbaustein, der während der Testimplementierung mit dem Testerkriterium „PASS" oder „FAIL" ergänzt wird. Mit Abschluss der Testausführung wird dieses Testkriteriumgesetzt, so dass sofort sichtbar ist, welche Funktionalität oder welcher Funktionsbaustein mit Fehlern behaftet ist. Andererseits wird in diesem Zusammenhang sichtbar, was erfolgreich gestestet wurde. Je genauer die Funktionsbausteine definiert sind, desto genauer ist die Fehleranalyse.
Testwartung erleichtern: Durch die funktionsorientierte Testimplementierung mit einem modularen Testaufbau aus Funktionstestbausteinen als Bausteinen des Testsystems wird die Wartung eines fehlerhaft implementierten Funktionstests erleichtert, indem ein einziger Funktionstestbaustein modifizierbar ist, so dass alle betroffenen auf diesen aufbauenden Tests automatisch die korrigierte Version verwenden. Eine Funktion wird dadurch getestet, dass alle ihre Funktionsbausteine nacheinander oder gleichzeitig gestestet werden. Für den Test eines Funktionsbausteins wird ein Testfall implementiert. Die Gruppierung der Testfälle bilden die Tests in Form einer Testprozedur ab, d.h. ein Testfall kann in einem oder mehreren Tests beteiligt sein. Die Modifikation des Testfalles bewirkt eine Modifikation aller Tests, in denen der Testfall involviert ist; dies auch flugzeugübergreifend.
Erzeugung, Anzeige und Speicherung der Daten/Konfigurationskontrolle (Speicherung, Aufbereitung, Auswertung und Präsentation von Testdaten)
Überwachung der Betriebszustände (siehe oben).
Einheitliches Datenbankkonzept zwischen den verschiedenen Datenbanken und Nutzern.
Verfolgbarkeit während eines Testablaufs / Verfolgbarkeit über einen Testprozeß aller am Test beteiligten Elemente.
Durch die vorstehend genannten Prozesse wird der Benutzer des erfindungsgemäßen Testsystems immer in der Lage sein, die ausgeführten Aktionen zu dokumentieren und dadurch die Qualitätssicherung zu gewährleisten.
Einzelheiten der Erfindung gehen aus den folgenden Figuren-Beschreibungen und den Patentansprüchen näher hervor.
Die Erfindung ist durch Figuren dargestellt; es zeigt
Fig. 1 Signal & Mapping Fig. 2 UUT Umgebungsintegration
Fig. 3 Verfolgbarkeit über einen Testprozeß
Fig. 4 Prozess-Übersicht
Fig. 5 Zusammensetzung des erfindungsgemäßen Testsystems aus Einzelmodulen;
Fig. 6 Testanordnung zum Testen von Komponenten und Systemen, in der die Elemente aus FIG. 4 nach Testsystem-Komponenten gegliedert sind;
Fig. 7 erfindungsgemäßes Verfahren zum Testen von Komponenten und Systemen;
Fig. 8 Ausführungsform des Verfahrens weist der Verfahrensschritt Vorbereiten eines Tests;
Fig. 9 Ausführungsform des Verfahrens zu Verfahrensschritt Vorbereiten mindestens einer Testkonfiguration;
Fig. 10 Ausführungsform des Verfahrens zu Verfahrensschritt Ausführen des Tests;
Fig. 11 Ausführungsform des Verfahrens zur Integration der Systemanforderung;
Fig. 12 Ausführungsform des Verfahrens zur Integration von Ressourcen im Testprozess;
Fig. 13 Ausführungsform des Verfahrens zur Integration einer Signalübersetzung.
In Fig. 1 ist die Abbildung der logischen Werte auf physikalischen Werte (Signal & Mapping) beim erfindungsgemäßen Verfahren dargestellt, wobei der generische Treiber (4.14; siehe dazu auch Fig. 4 -> Elemente 4.13-4.20) die Aufgabe übernimmt, die physikalischen Parameter (1.1 ) (z.B.. Temperatur- und Druckwerte) automatisch dem entsprechenden Bus (1.3) zuzuordnen (Mapping). Ihnen wird ein logischer Wert zugewiesen (4.14 mapping: logical 1 / 2 / 3), d.h. ein physikalischer Wert kann für verschiedene Busse (1.3: Bus 1 , Bus 2, Bus 3, ...) unterschiedliche logische Bezeichnungen haben (Signal). Die Abbildung jedes physikalischen Wertes erfolgt per generische Treiber (4.14), so dass jeder physikalische Parameter (1.1) eine oder mehrere logischen Sichten haben kann; zusätzlich wird eine Signalposition auf dem Bus vergeben, die der realen Position im Flugzeug entspricht. Die logischen Sichten werden vom Treiber genutzt und repräsentieren die Ausprägung eines physikalischen Parameters auf ein bestimmtes Busmedium.
Die Fig. 2 zeigt die Integration der UUT (2.2) mit ihrer Umgebung (2.3), wobei die UUT in jede beliebige reale Umgebung integriert sein kann, mit der ausgedrückt wird, dass die erfindungsgemäße Steuereinheit in der Lage ist, die empfangenen und gesendeten Signale des SUT bzw. der UUT zu beobachten (2.1). Das erfindungsgemäße Testsystem benutzt im Gegensatz zu den oben beschriebenen bekannten Lösungen mit fixen Treibern einen generischen Treiber (Signal configuration, integriert in 4.14 configurable test engine). Das erfindungsgemäße Verfahren mit generischem Ansatz heißt, dass die Umgebung des Prüflings (2.3) anhand von Signalgebern (2.1 hier: Transducer, können Sensoren, Fühler, etc. sein) geprüft wird. Dabei wird zunächst nicht der Prüfling (UUT) (oder das SUT) getestet, sondern das Testsystem, nämlich ob die gesendeten Signale richtig ausgewertet werden. D.h. der Schwerpunkt liegt zunächst nicht wie bei bekannten Lösungen auf dem UUT, sondern auf den Schnittstellen des UUT bzw. SUT (2.7 und 2.8). Da die erfindungsgemäße Vorrichtung eine direkte Verbindung zu den UUTs besitzt, müssen nicht schon vorher fixe Schnittstellen definiert werden; d.h. festgelegt welcher Bus benutzt werden soll. Beim Stand der Technik gemäß der o.g. US 5 023 791 werden zwei zusätzliche SUTs verwendet (SUT redundant), um redundante Signale zu erzeugen. Bei dem erfindungsgemäßen Testsystem wird hingegen das Signal nur einmal in der Testengine (2.3) gehalten und die Redundanz wird durch zweimalige zeitgleiche Sendung des gleichen Signals softwaremäßig erzeugt. Bei o.g. Schrift kann nur getestet, jedoch nicht simuliert werden; dagegen erschafft das erfindungsgemäße Testsystem eine bestimmte Umgebung durch Simulation (2.6) in der konfigurierbaren Testengine. Dies resultiert darin, dass bei dem Testsystem im Test eines UUT (2.2) Signale (2.8 und 2.7) (durch die Softwarelösung des generischen Treibers) sowohl empfangen als auch gesendet (2.7 und 2.8) und ebenso ausgewertet werden können (2.1). In o.g. Schrift ist eine solche umkehrbare Richtung von Sender und Empfänger nicht möglich. Dort würde die Umkehrung von Sender/Empfänger einen Neuaufbau des Teststandes und einen zusätzlichen Testfall erfordern, was bei dem erfindungsgemäßen Testsystem vermieden wird.
Fig. 3 gibt an, auf welche Weise die Verfolg barkeit über einen Testprozeß bei dem erfindungsgemäßen Testsystem erreicht wird. Da Systemrequirements (3.1 ) immer mit ihrem UUT (2.2) eine Einheit bilden (symbolisiert duch SysReqs Workflow), das erfindungsgemäße Testsystem (2.5) aber in der Lage ist, die UUT in verschiedene Umgebungen zu integrieren (2.5 Workstation), müssen Systemrequirements (3.1 ), UUT (2.2) und Testumgebung (2.6) bei einem Test zusammengeführt werden. Somit werden die Systemrequirements (3.1 ) und das UUT (2.2) nicht nur in einer Testumgebung (2.6) getestet und ausgewertet, sondern in verschiedenen Testumgebungen. D.h. ähnliche Tests finden unter unterschiedlichen Rahmenbedingungen statt, die auch der realen Flugzeugkonfiguration entsprechen und eine Modellierung der Systemrequirements ermöglichen.
Das dargestellte Ablaufdiagramm sagt aus, dass die Modellierung der Systemrequirements, und also die Testrequirements (integriert in einem Computer Aided Test Generation Assistent CATEGA 2.5), anhand von Testfällen (integriert in 3.2) getestet werden. Die Vorgehensweise sollte so sein, dass die Modellierung eine hohe Testabdeckung garantiert. Ist der Test durchgeführt, wird ein Systemrequirement (nur für diese Testumgebung) als bestanden oder nicht bestanden markiert und zurückgegeben (symbolisiert durch Pass / Fail criteria). Systemrequirements sind somit ein integrativer Bestandteil des Testprozesses.
Dadurch, dass Systemrequirements (3.1 ) in verschiedenen Umgebungen (2.5) getestet und ausgewertet werden, kann auch eine Multi-System-Test-Umgebung (2.2, LJUT 1 , UUT2, UUT3, ....) geschaffen werden, in der die Systemrequirements integriert werden. Zudem ist die Durchführung von Integrations-Tests, d.h. die Verschaltung mehrerer Teststände (SIB), möglich. So können systemübergreifende Tests durchgeführt werden, statt nur einzelne UUTs zu testen.
Die Bildelemente 2.6, 3.4 und 2.2 zeigen den Vorgang Erzeugung und Speicherung der Betriebskonfiguration.
Um die Testumgebung (2.5) für das UUT (2.2) herzustellen, müssen folgende Elemente zur Verfügung gestellt werden:
Alle Echtteile (Controller), die nur zu der Testumgebung gehören und kein UUT sind
Für nicht vorhandene Echtteile oder nicht in der Testumgebung realisierbare Zustände werden Simulationen mit Hilfe eines Simulators erstellt
Die Fig. 4 zeigt eine Prozessübersicht des erfindungsgemäßen Verfahrens.
Die Prozesselemente bzw. Module sind dargestellt, 4.9 - 4.12, 4.2, 4.3, 4.6, 4.22- 4.24 zeigen die Integration und Identifikation der Systemkomponenten und es ist erkennbar, dass bei dem erfindungsgemäßen Testsystem modulare Systeme (die einzelnen Bildelemente) leicht integrierbar sind und eine starke Vernetzung von Datenbusstrukturen abgedeckt werden kann. Außerdem sind Testaktivitäten manuell und automatisiert ausführbar bei klaren Schnittstellen zwischen den Prozessen (Systementwicklung / Realisierung / Testdurchführung).
In den Prozesselementen 2.2, 4.2-4.5 und 4.25 sind die Ressourcen dargestellt, worunter zu verstehen ist, dass alle SUTs (2.2 Prüflinge) und Testeinrichtungsteile (4.5) dem erfindungsgemäßen Testprozess durch eine Importfunktion bekannt gemacht werden und in fester Verbindung mit den Testelementen stehen (4.6), welche ebenfalls versionisiert verwaltet werden. Testeinrichtung kann aus mehreren Komponenten bestehen:
Echtteile (Parts, SUT) (2.2): Alle Komponenten oder Teile, die in einem realen Flugzeug eingebaut werden, unabhängig davon, ob sie den Prüfling oder die Testumgebung abbilden
SGR (Software Ground Repository) (4.4): Aus diesem Depot können zu einer bestimmten Version des SUTs die entsprechenden Softwarekomponenten geladen werden und somit eine spezielle Ausprägung der konkreten SUT-Version darstellen. Dies bedeutet: Das SUT mit einer bestimmten Softwareversion entspricht einer Konfiguration bzw. dem Resource Management Modul (4.3). In diesem Modul sind die Softwarekonfigurationen für alle Prüflinge und Testumgebungen abgebildet.
Damit diese Konfiguration (4.3) vollständig ist, muss sie mit bestimmten Einstellungen (Pin-Belegung), der Hardware entsprechend, ergänzt werden. Dafür werden SUT- spezifische Einstellungen (Zeichnungen, Listen und Modellsimulationen) (4.25) eingelesen und mit der Konfiguration verlinkt. Somit wird die reelle Flugzeugeinstellung nachgebildet oder simuliert.
Das heißt: Jede gültige vollständige Konfiguration besteht aus:
Echtteil(en) und/oder Testeinrichtung(en)
Einer Softwarekonfiguration
Einer Hardwarekonfiguration
Um dieses Verfahren realisieren zu können, müssen die Testsysteme so aufgebaut werden (Test facility build-up) (4.5), dass sie den realen Vorgaben entsprechen. Dieses Verfahren kann zu jedem auszuführenden Test (4.28) die Testeinrichtung (4.3), bestehend aus SUT und/oder Testumgebung(2.2), verlinken und somit kann zu einem späteren Zeitpunkt der Test mit der gleichen Umgebung wiederholt werden. Somit ist gewährleistet, dass jeder Test jederzeit in der richtigen Umgebung nachgestellt werden kann.
Prozesselemente 4.6 und 4.7: Zu jeder Teststandkonfiguration (4.3) sind Signale (4.14) zugeordnet (siehe Signalübersetzung) und somit steht der konfigurierte Teststand (4.6) mit seinen integrierten Signalen den auszuführenden Skripten der Testfälle (manuell oder automatisch) (4.11 ) zur Verfügung. Da mehrere Teststandkonfigurationen erstellt werden können, muss zu jedem Test-Modul (Gruppierung von Testfällen) (4.12) eine bestimmte Teststandkonfiguration zugeordnet werden. Durch diese Vorgehensweise wird jeder Test vollständig beschrieben und stellt eine verfolgbare, reproduzierbare, wiederherstellbare und wiederholbare Testgesamtkonfiguration dar.
Die Prozesselemente 4.6, 4.7, 4.11 , 4.14 und 4.19 beziehen sich auf Verfolgbarkeit und Verfolgbarkeit über einen Testprozeß bei erfindungsgemäßen Testabläufen. Den Testmodulen 4.6, 4.7, 4.11 , 4.14 und 4.19 werden in diesem Schritt die Betriebskonfiguration (4.3) zugeordnet, so dass Systemrequirements (4.8) mit ihrer Testumgebung (2.5) immer eine spezifische Version eines Tests bilden.
In den Prozesselementen 4.13 bis 4.20 ist der Generic Driver (4.14) dargestellt, der dazu verwendet wird, die UUT(2.2) in die Testumgebung (3.7)(s. Fig. 1) zu integrieren. Im folgenden eine nähere Beschreibung der Abläufe (vgl. auch Fig.2).
Für jeden Flugzeugtyp existieren Beschreibungen aller Schnittstellen zwischen den einzelnen Systemen (4.13) in Form einer Signalliste pro System (4.16), die den Datenaustausch spezifizieren. Da jeder Flugzeugtyp mit unterschiedlicher Infrastruktur ausgestattet ist, existieren zusätzlich Netzwerkkonfigurationen (4.15), die den Datentransport und Kommunikation zwischen Systemen bestimmen. Netzwerkonfiguration (4.15) und Schnittstellen (also Signale 4.16) werden versioniert in eine Datenbank (A/C-baseline 4.13) gespeichert sind. Der „Generic Driver" hat dabei die folgenden Aufgaben:
Signale und Netzwerkkonfiguration zu importieren
Konfiguration auf Vollständigkeit und Fehlerfreiheit prüfen (4.18)
Automatische Berichterstattung (Teil der Dokumentation) bei einer fehlerhaften Konfiguration (4.20)
Eingänge & Ausgänge des Teststands (SIB (4.6); I/O description(4.19)) werden importiert.
Die importieren Signale werden der Netzwerkkonfiguration entsprechend auf die Eingänge & Ausgänge des Teststandes im Signal & Mapping abgebildet (4.17)
Damit wird aus dem generischen Treiber eine für diesen UUT typisierte Version automatisch erstellt und im Test durch die Signalkonfiguration integriert (4.14). Je nach System ist der generische Treiber immer in der Lage, einen bestimmten Typ des UUTs in eine bestimmte Testumgebung zu integrieren (4.6).
Durch die Fähigkeit des generischen Treibers, sich automatisch anzupassen, wird die UUT(2.2) automatisch in der richtigen Umgebung integriert sein, so dass fixe Treiber und Busadaption entfallen. Ein Unterschied zur vorstehend genannten US 6 128 759 besteht somit darin, dass auf einen dort verwendeten Busadapter (110) und dessen fixe Treiber (120-124) verzichtet werden kann, da bei dem erfindungsgemäßen Testsystem die UUT direkt mit dem generischen Treiber kommuniziert (siehe dazu auch Fig. 2 und 3). Somit ist eine Adaptation auf verschiedene Bus-Einheiten möglich (siehe dazu auch Fig. 1), während bei anderen Verfahren alle physikalischen Werte bei der Initialisierung typisiert werden müssen.
Das erfindungsgemäße Testsystem (2.5) gewährleistet somit Harmonisierung, Begleitung und Dokumentation des Testprozesses, in dem alle möglichen Eingänge und relevanten Einflüsse der Testumgebung (4.3, 4.14) zu einer Einheit integriert werden (4.6). Die Harmonisierung wird durch Integration der Systemrequirements (4.8) in den gesamten Testprozess gewährleistet. Der Testprozess besteht aus den Teilen: Testplanung (4.9), Testfallermittlung (4.10), Testfallumsetzung in ablauffähiges Scripte (4.11 ), Problemreporting (4.23), Testausführungsreporte (4.22) und Verifizierung der Ergebnisse (4.24).
Eine Begleitung erreicht das erfindungsgemäße Testsystem (2.5) durch Dekomposi- tion der Systemrequirements (4.8) während der Testdesignphase (4.28) und Zuordnung der zu entwickelten Testrequirements (4.10 ; siehe dazu auch Fig 5). Ausgehend vom Ergebnis des Testdesigns werden Testcases (4.11) (ablauffähige Testscripte: manuell oder/ und automatisch; siehe dazu auch Fig. 5) ausgearbeitet. Die Dokumentation wird durch eine Reihe von Maßnahmen wie Importieren der Systemanforderungen (4.8 nach 4.9) und Verlinkbeziehung erzielt. So werden Systemanforderungen (4.8), bzw. Testanfragen per Importfunktion mit dem Testplan (4.9) und dem Testdesign (4.10) verlinkt, so dass sie ein integrativer Teil des Testprozesses werden (siehe dazu auch Fig. 5).
Durch das Importieren der Systemanforderungen (4.8) in den Testprozess sind in den gesamten Prozessmodulen (TEP 4.9, TD 4.10, TC 4.11 , TP 4.12) die dazugehörigen zu testenden Systemanforderungen bekannt und können somit jedem Testfall (4.11 ), Testbericht (4.22), Testausführung (4.28) und Testauswertung (4.24) mit den entsprechenden Systemanforderungen (4.8) in Beziehung gesetzt werden.
Diese Verlinkungsbeziehungen stehen unter Versionskontrolle. Dieser Umstand versetzt den Anwender in die Lage, zu jedem Zeitpunkt und Testfall die Verbindung zu einer bestimmten versionisierten Systemanforderung herzustellen.
Des weiteren ist das erfindungsgemäße Testsystem durch diese Signalüberset- zungs-Module (4.17, 4.18) gekennzeichnet, wobei die Signalübersetzung ein Prozess ist, um formal definierte Schnittstellen (4.16), Netzwerkstrukturen (4.15) und Busdefinition (4.19) automatisch in ausführbare Skripte (4.14) zu führen. Diese ausführbare Skripte werden dafür eingesetzt, um den Teststand automatisch zu konfigurieren (4.6), sodass er die Rolle des realen Systems übernimmt.
Der Übersetzungsprozess (4.17, 4.18) ist in dem erfindungsgemäßen Testsystem durch ein Zusatzmodul realisiert. Mit diesem Modul werden folgende Punkte realisiert:
Signale (4.16), die die physikalischen Parameter des Systems abbilden, werden for- malisiert (4.17), so dass sie softwaremäßig gelesen werden können (4.14)
Alle Netzwerk-relevanten Daten werden importiert, sodass die reale Systemwelt künstlich nachgebildet wird (4.15 zu 4.18 und 4.17)
Die für den Teststand relevante Hardwarekonfiguration (4.3) wird eingelesen, um die realen Schnittstellen auf die Schnittstellen des Teststandes abzubilden (4.6)
Aus den vorliegenden Informationen werden die Signale typisiert, je nachdem auf welchem Bus sie gesendet werden (4.17)
Die typisierten Signale werden dann mit den I/Os (Ein- & Ausgänge) (4.19) des Teststandes verbunden und auf Richtigkeit geprüft (4.20)
Diese Schnittstellenbeschreibung wird dann in eine Konfigurationsdatei ge-speichert (4.14). Anhand dieser Konfigurationsdatei, kann ein bestimmtes System in diesem typisierten Teststand repräsentiert werden (4.6)
Wenn diese Konfiguration geladen ist, ist der Teststand in der Lage die Schnittstellen des Systems zu simulieren, zu stimulieren und zu steuern Zusätzlich können mit dieser Methode mehrere Systeme miteinander geschaltet werden (Multisystemtest). Dies gewährleistet, dass alle am Test beteiligten Systeme, durch validierte Schnittstellen miteinander kommunizieren.
Network configuration (4.15): Formelle (per Software auswertbare) Beschreibung aller am Netwerk beteiligten Elemente.
Signal description (4.16): Formelle (per Software auswertbare) Beschreibung der Systemschnittstellen (Signale und PIN-Position).
A/C-Baseline (4.13): Die Verwaltung der Bezugsdateien aller miteinander verbundenen Systeme werden hier realisiert, so dass die Kompatibilität zwischen den einzelnen Systemen gewährleistet wird, z.B.. dass die Version 1 von System A nur mit Version 2 von System B zusammenspielen kann, aber nicht mit Version 3 von System B, auch wenn diese aktueller ist. Pro Test dürfen alle Konfigurationen nur aus einer bestimmten Baseline stammen.
Damit ein Prüfling (2.2) überhaupt automatisch konfiguriert werden kann, muss das erfindungsgemäße Testsystem aus informellen Dokumenten(Spezifikationen), formelle Skripte ( in 4.1 1 ) oder Konfigurationen (4.3) erstellen. Diese automatisch ladbaren Skripte werden mit den echten Signalen (4.14) verlinkt und per SIB-Konfiguration (4.6) dem Testprozess bekannt gemacht und gehören zum Test. Somit ist das erfindungsgemäße Testsystem in der Lage jederzeit zu berichten, mit welcher Konfiguration, bzw. Ausprägung des Prüflings, gestestet worden ist:
Network-Config. (4.15) und Signal-Config. (4.16) sind informelle Dokumente, die auf Richtigkeit (Correctness) (4.18) geprüft werden
Signal & Mapping (4.17) entsprechen dem Formalisierungs-Vorgang
Aus dem vorgehenden Prozess entstehen die Signal-Konfigurationen (4.14), die automatisch geladen werden können und ein Teil der SIB-Konfiguration (4.6) abbilden. Diese entsprechen den formellen Dokumenten.
Damit die Testskripte der Testfälle (4.11 ) mit den entsprechenden Variablen (Signalen) deklariert werden können, werden die oben erstellten Signalkonfigurationen (4.14) in die Testfälle eingebunden (4.7) und aus denen interne Variablen definiert, die den Testverlauf (4.9-4.12 und 4.28-4.24) bestimmen und aufnehmen, so dass eine spätere Auswertung, in bezug auf die A/C Baseline (4.13), möglich ist.
Signal & Mapping (4.17): Mit Signalbescreibung (signal description) (4.16) werden alle physikalischen Parameter dargestellt und zwar in Abhängigkeit davon, auf welchen Medien sie übertragen werden (4.15).
Ein Signal stellt folgendes dar:
Physikalischer Parameter, z.B.. Temperaturwert (4.16)
Übertragungsmedium, TCP/l P-Verbindung (4.15) Übertragungscharakteristiken, z.B.. Framerate, Refreshrate, ...
Sender (Anfangssystem) (4.19)
Empfänger (Endsystem) (4.19)
Die Verbindung dieser Signale mit den Endpunkten des Anfangs, bzw. Endsystems, werden durch die Signal & Mapping Dateien (4.17) realisiert und stehen ab diesem Zeitpunkt dem erfindungsgemäßen Prozess zur Verfügung.
Der Prozess der Testbench Integration (SIB Configuration) (4.6) als weiterer erfindungsgemäßen Modul ist die Zusammenführung von:
Signalübersetzung (4.14)
Ressourcen (4.3)
Der Zweck dieses Prozesses ist die Ressource (4.3 Software, Hardware und Konfiguration) mit den Schnittstellen (4.14 Signale und Mapping) zu versehen, so dass externe Prozesse, bzw. Anwendungen mit dem Testaufbau (4.5 testbench) Daten austauschen können. Dies bedeutet, dass der Testaufbau zu einer integrativen Einheit moduliert wird, mit der Fähigkeit, mit der Umgebung zu kommunizieren.
Das bisher verwendete Prinzip (d.h. Stand der Technik ) besteht darin, Systeme über Ihre Schnittstellen zu definieren, ohne die Inhalte kennen zu müssen, z.B. internes Verhalten / Zustand eines Systems. Das erfindungsgemäße Testsystem hingegen, entwickelt die Schnittstellendefinition (4.14) in Abhängigkeit der internen Eigenschaften des Systems, so dass durch die externen Schnittstellen auch interne Funktionalitäten stimulieren oder gesteuert werden können. Dadurch wird die ehemalige Kapselung des Systems aufgehoben und das erfindungsgemäße Testsystem erreicht somit, dass das black-box-prinzip zu einem grey-box-prinzip gewandelt wird.
Fig 5 zeigt, wie sich das erfindungsgemäße Verfahren aus den hauptsächlichen Einzelmodulen zusammensetzt:
TEP: Test (Execution) Plan (4.9)
TD: Test DesignAEntwurf (4.10)
TC: Test CaseAFall bzw. Gegenstand (4.11 )
TP: Test ProcedureΛ-Ablaufvorgang (4.12)
TE: Test executionΛAusführung (5.11)
Im Modul "Test Execution-Plan" (4.9), also der Testplanung, wird der komplette Testablauf (4.9 -5.18) geplant. Es werden Anforderungen (3.1 Systemrequirements), Spezifikationen, Standards, Aufgaben und Bedingungen für den gesamten Test definiert. Jeder einzelne Prozessschritt während des Tests wird anhand von Ressourcen (5.18 und 4.6), Personal, Zeit und Risiko spezifiziert und definiert. Mit der Testplanung (4.9) werden alle zu testenden Objekte (5.2 Test Items) bekannt gegeben, zusammen mit den zu testenden Funktionen (5.3 Test Features) jedes einzelnen Objekts. Den Funktionen (5.3) werden die Systemrequirements (3.1 ) entsprechend zugeordnet. Damit wird in diesem Prozess-Schritt anhand der Test Features die Grundlage für die Teststrategie bereit gestellt.
Im Modul "Test Design" (4.10) findet die Spezifikation der Testplanung (4.9) statt. Es wird die Teststrategie (4.10, 5.5-5-7) (oder auch mehrere) entwickelt, festgelegt und für die folgenden Tests (4.11 ) vorgegeben. Es entstehen sogenannte Testdesign-Levels (5.8), die mehrstufig sein können. Diese Levels bestimmen die Anzahl der zu testenden Methoden und Funktionen. Dabei werden Testobjekte gebildet (5.5), die aus einem oder mehreren Testrequirements (5.6) bestehen. Diesen Testrequirements werden die in der Testplanung (4.9) spezifizierten Testfeatures (5.3) zugeordnet; je nach Teststrategie unterschiedlich. In diesem hierarchischen Verfeinerungsprozess werden die Systemrequirements (3.1) in beliebig kleine Schritte zerlegt (5.7 Tag). Ebenso kann jedes Testrequirement (5.6) mit einer unterschiedlichen Intensität (5.7 Depth) getestet werden.
Im Modul "Test Gase" (4.11 ) wird in der vom Tester im Testdesign (4.10) spezifizierten Testumgebung (4.6, 5.18) und Randbedingungen ein UUT getestet. Es werden die einzelnen Testschritte (4.12) festgelegt und die einzelnen pass/fail-Kriterien angeben. Mit Hilfe eines Test Gase (4.11 ) lässt sich nun prüfen, ob die vom Tester erstellten Testrequirements (5.6) in der Testumgebung (4.6, 5.18) mit den Signalen (5.16) aus der realen Systemwelt übereinstimmen. Dies kann wahlweise auch vollautomatisch geprüft werden. Somit wird im Modul "Test Case" (4.11) das im "Test Design" (4.10) entwickelte Test Design Document (4.28) in ausführbare Test-Scripte umgesetzt (4.22), wobei mehrere verschiedene Scriptformen (4.22) in Frage kommen.
Im Modul "Test Procedure" (4.12) werden eine oder mehrere Test Case (4.11) zu- sammengefasst und für die Test execution (5.11 ) vorbereitet. Nur eine Test procedure (4.12) kann einer Test execution (5.11 ) zugeordnet werden, in welcher der Test (5.9) ausgeführt wird. Datum und Uhrzeit werden angegeben, ebenso mit welchen Ressourcen (4.6, 5.18) getestet wurde. Es ist möglich, verschiedene Konfigurationen (4.6) eines Teststandes zu erstellen und einer Test execution (5.11) zuzuordnen. Alle durchgeführten Schritte werden dokumentiert (Teilaspekt der Dokumentation).
In der "Test verification" (5.13) werden die Testergebnisse (5.12) präsentiert. Mit Hilfe von Problem Reports (4.23) ist es möglich, Probleme eines Tests mit dessen verwendeten Ressourcen anzugeben und an verschiedene Stellen zu senden.
Im Modul „Test Execution" (5.11) wird der in der Test procedure (4.12) definierte Test (5.9) mit der Ressource (4.6 und 5.18) verbunden und ausgeführt. Für die Testausführung wird ein Bericht erzeugt (4.23 Teil eines Test reports). Die Testergebnisse (5.12) werden anschließend ausgewertet und bei Fehlern werden Fehlerberichte erstellt (4.23 problem report). Nach Beendigung einer Testphase werden alle zugehörigen Test execution reports und problem reports zusammengestellt in einem umfassenden Report, dem Test report (4.24 Test reports). Dieser wird in ein Dokumenten-Versionsmanagement-System eingepflegt (4.24 und auch Fig 4/ 4.26).
Problem reports werden ausgewertet und bei Bedarf erfolgt eine Neu- oder Weiterentwicklung des betroffenen Equipments ( siehe dazu auch Fig 4/4.27 equipment development).
Bei dem erfindungsgemäßen Verfahren zumTesten von Komponenten und Systemen ist gewährleistet, dass die Harmonisierung und Dokumentation des Testprozesses, in dem alle möglichen Eingänge und relevanten Einflüsse der Testumgebung zu einer Einheit integriert werden. Im einzelnen schlüsseln sich die Merkmale wie folgt auf:
Harmonisierung: Die Harmonisierung wird einerseits durch die Zusammenführung der Testumgebung durch Integration von Ressourcen (4.3), Signalkonfiguration (4.14) , I/O- Beschreibung (4.19) und Signalen (4.7) zu einer Test bench Konfiguration (4.6) gebildet. Diese Harmonisierung wird ergänzt durch eine Verbindung mit einem Testmodul (4.12) und dessen Testfällen (4.11 ), die die System requirements (4.8) abbilden. Die Zusammenführung der Testumgebung mit den Systemrequirements wird in der Test execution (4.28) realisiert.
Qualitätssicherung gewährleistet durch Einzelprüfung der Zusammenführungen während der Harmonisierung auf Konsistenz und Validität, gewährleistet durch den Baustein Correctness check (4.18); diese Prüfung ist ebenso in den Modulen (4.8-4.12, 4.2, 4.3, 4.6, 4.28) integriert.
Identifikation der Komponenten als klare Schnittstellen zwischen den Prozessen (Systementwicklung / Realisierung / Testdurchführung) gewährleistet durch die einzelnen erfindungsgemäßen spezifischen Module (4.8-4.12, 4.2, 4.3, 4.6, 4.28).
Verfolgbarkeit über einen Testprozeß und Verfolgbarkeit durch Schnittstellenstruktu- rierung bestehend aus den Elementen 4.8-4.12, 4.2, 4.3, 4.6, 4.28.
Dokumentation des Testprozesses mittels relevanter Modulen ausgestattet mit einem Reporting-Modul (4.20), der einen Bericht über den aktuellen Status, die Historie und alle Beziehungen des Moduls zu anderen Modulen als Dokumentation mit den Elementen 4.20, 4.21 , 4.22, 4.26 erstellt.
Das erfindungsgemäße Verfahren zumTesten von Komponenten und Systemen weist vorzugsweise die weiteren Eigenschaften auf, dass die Integration der Systemanforderung mittels der folgenden Merkmale bzw. Prozess-Elemente und Verfahren realisierbar ist:
Import der Systemanforderungen (4.8) in den Testprozess und Formalisierung und Versionierung der Anforderungen mit dem Test execution plan Modul (4.9);
Versionierte Systemanforderungen stehen dem Test design (4.10) zur Verfügung; Kennzeichnung von Änderungen der Systemanforderungen (4.8) durch neue Importe oder Modifikation (Neu, Bearbeiten, Löschen) sowie Anzeige einer Statusänderung bei Test design (4.10);
Reproduzierbarkeit eines Tests mittels Versionierung der Testfälle (4.11) und der Tests (4.12);
Modularer Aufbau von dem erfindungsgemäßen Testsystem (2.5) (d.h. klare Schnittstellen zwischen den Modulen); jeder definierte Modul (4.8-4.12, 4.2, 4.3, 4.6, 4.28) ist mehrfach und versions-übergreifend verbindbar.
Das erfindungsgemäße Verfahren zumTesten von Komponenten und Systemen weist bevorzugt die weitere Eigenschaft auf, dass Ressourcen im Testprozess durch folgende Merkmale und Verfahren integriert sind:
Alle relevanten Prüflinge (4.1) werden in dem erfindungsgemäßen Testsystem (2.5) durch den Goods receipt Modul (4.2) importiert und formalisiert.
Weitere für den Testaufbau relevanten Softwareelemente (Software-Depot, 4.4) werden ebenfalls importiert und formalisiert.
Zeichnungen, Verdrahtungen, Komponenten und Simulationen der Testumgebung (4.25) werden ebenfalls importiert und formalisiert (4.5) und stehen dem Testaufbau zur Verfügung.
Die Zusammenführung aller Elemente (4.2, 4.4, 4.5) stellt die Gesamtkonfiguration des Testes dar und wird versioniert durch den Resource management Modul (4.3) verwaltet.
Der Modul (4.3) steht jedem Test zur Verfügung und wird über die SIB-Konfiguration (4.6) dem Testprozess (4.28) bekannt gemacht.
Die Ressourcen-Komponenten (4.3) sind versioniert definiert und auch versioniert mit einem Testausführungs-Modul (4.28) verlinkt.
Lokalisierung eines fehlerhaften Verhaltens erleichtert durch modulare Kapselung der Zusammenhänge und Verbindung durch klare Schnittstellen der Elemente 4.8-4.12, 4.2, 4.3, 4.6, 4.28.
Das erfindungsgemäße Verfahren zumTesten von Komponenten und Systemen weist vorteilhaft die weiteren Eigenschaften auf.dass eine Signalübersetzung integriert ist, mit folgenden Merkmalen und Verfahrensweisen:
Alle relevanten Schnittstellendefinitionen (4.14) werden importiert und formalisiert und typisiert in der Network configuration (4.15) und in der Signal description (4.16) gegliedert.
Die Schnittstellendefinitionen werden mittels Correctness check (4.18) auf Konsistenz und Korrektheit geprüft. Bei einem Fehler wird ein Bericht und eine Änderungsanforderung mittels Failure report (4.20) erstellt. Die Ein-&Ausgangsbeschreibungen (4.19) werden mit den formalisierten Daten (Cor- rectness check, 4.18) per Signalmapping (4.17) zusammengeführt zu einer Signalkonfiguration (4.14).
Diese Erzeugung, bzw Zusammenführung wird in der SIB-Konfiguration (4.6) angezeigt (Status) und gespeichert.
Die gespeicherten Konfigurationen bilden die Grundlage für die Testautomatisierung und werden über den CVS-Revisionierungs-Server (4.7) mit dem Testfall (4.11 ) verbunden; dort existiert ein Skriptgenerator, der als Eingangsinformation die Signale (aus 4.7) und dem Testfall (4.11) zu einem automatisch ausfühbaren Test verbindet.
Das erfindungsgemäße Verfahren zumTesten von Komponenten und Systemen weist bevorzugt die weiteren Eigenschaften auf, dass die Test bench Integration mittels folgender Verfahrensweisen realisierbar ist:
Die Test bench Integration besteht aus der Zusammenführung folgender Module:
Aus den in der Test facility (4.5) erstellten Aufbauten;
Aus den Echtteilen des Goods receipt Moduls (4.2);
Aus den in der Software Ground Repository (4.4) zur Verfügung gestellten Software.
Die Zusammenführung aller Elemente ergibt eine integrierte Testbench (4.6) zur LJ- berwachung der Betriebszustände, wobei das erfindungsgemäße Testsystem (2.5) mit Hilfe des dazu verlinkten Testfalls (4.11) durch den CVS-repository (4.7) mit dem SUT oder UUT (2.2) kommunizieren, es ansteuern, stimulieren und /oder testen kann.
Das erfindungsgemäße Verfahren zumTesten von Komponenten und Systemen weist vorzugsweise die weiteren Eigenschaften auf, dass Testwartbarkeit und Erweiterbarkeit durch folgende Merkmale integrierbar sind:
Testfälle (4.11 ) werden allgemein gültig entworfen und erst typisiert durch die Verlin- kung mit der SUT-abhängigen Konfiguration der Elemente 4.6 , 4.7. Ändert sich die Konfiguration von 4.6, 4.7 bleibt der Testfall gültig, da die Anpassung in der Konfiguration integriert ist.
Modifikation von vorhandenen Konfigurationen oder Eingabe neuer Konfiguration nur mit einer Skriptänderung der Schnittstellendefinition (4.14) durchführbar.
Grundlegende Änderung der Schnittstellenbeschreibung bzw. Datenbank (4.13) werden nur durch Anpassung der Skripte in den Elementen 4.17 und 4.18 umgesetzt; alle anderen Modulen sind von dieser Änderungen nicht betroffen und bleiben unverändert.
Kommen Funktionalitäten zu einem UUT /SUT (2.2) neu hinzu, erfolgt die Anpassung mit dem gleichen Verfahren.
FIG. 6 zeigt eine Testanordnung zum Testen von Komponenten und Systemen, in der die Elemente aus FIG. 4 nach Testsystem-Komponenten gegliedert sind. Eine Testanordnung zum Testen von Komponenten und Systemen hat ein Testsystem, welches Schnittstellen zum Anschluss eines Unit Under Test (UUT) aufweist, einer Steuereinheit zur Ansteuerung des Testsystems, einer Datenbank, welche Daten über Komponenten- und/oder Systemrequirements des UUT und Daten über einen Test aufweist.
Das Testsystem zum Testen von Komponenten und Systemen weist gemäß der Erfindung folgende Testsystem-Komponenten auf: eine Testvorbereitungs-Komponente (6.1), die als Input eine Systemspezifikation erhält, diese Systemspezifikation zu einer implementierten Testanweisung aufbereitet, und diese implementierte Testanweisung ausgibt; eine Testkonfigurations-Komponente (6.2), die als Input eine Baseline für eine Gesamtsystemkonfiguration erhält, diese Baseline zu einer Testkonfiguration aufbereitet, und diese Testkonfiguration ausgibt; eine Testausführungs-Komponente (6.3), die als Input unter anderem die implementierte Testanweisung und die Testkonfiguration erhält, diese ausführt und das Testergebnis ausgibt.
Die Testvorbereitungs-Komponente (6.1) ist derart ausgestaltet, dass die implementierte Testanweisung immer an die Systemspezifikation angepasst ist.
Die Testkonfiguration-Komponente (6.2) ist derart ausgestaltet, dass die Testkonfiguration immer an die Gesamtsystemkonfiguration angepasst ist.Eine erfindungsgemäße Testanordnung zum Testen von Komponenten und Systemen umfasst vorzugsweise weiterhin eine Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur.
Vorzugsweise umfasst die Einrichtung zur Assistenz bei dem Erstellen einer Test- Prozedur ein Modul zum Erstellen eines Test Execution Plan.
Vorzugsweise umfasst die Einrichtung zur Assistenz bei dem Erstellen einer Test- Prozedur ein Modul zur Spezifikation der Testanordnung und des UUT.
Bevorzugt umfasst die Einrichtung zur Assistenz bei dem Erstellen einer Test- Prozedur ein Modul zum Erstellen eines Test Design.
Vorteilhafterweise umfasst die Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur ein Modul zum Erstellen von Test Cases.
Vorzugsweise umfasst die Einrichtung zur Assistenz bei dem Erstellen einer Test- Prozedur ein Modul zum Erstellen von Test Scripten.
Bevorzugt umfasst die Einrichtung zur Assistenz bei dem Erstellen einer Test- Prozedur ein Modul zum Erstellen eines Test Execution Plan unter Verwendung der Test cases.
Die Verfolg barkeit der Eingangsdaten und erzeugten Daten durch Schnittstellenstruktur und Datenhaltung und Datenstruktur sei an folgendem Beispiel erläutert. Die Systemspezifikation enthält Systemrequirements 4.8 und Systemsignale, z.B. Spannungsdaten.
Die Testvorbereitungs-Komponente 6.1 ist derart ausgestaltet, dass die implementierte Testanweisung immer an die Gesamtsystemkonfiguration angepasst ist. Beispielsweise wird bei einer Änderung eines Anforderungsdatums "< 5 V" in "< 5.5 V" die Testimplementierung angepasst.
Das erfindungsgemäße Testsystem ist ein einheitliches System mit definierten Schnittstellen zwischen den Komponenten 6.1 , 6.2 und 6.3 derart, dass Änderungen in den Eingabedaten automatisch weiterverfolgt werden und die Tests ensprechend geändert werden. Alle von den Änderungen betroffenen Komponenten werden dadurch automatisch als ungültig gekennzeichnet, bis sie nach den geänderten Vorgaben erneut getestet worden sind.
Die Testkonfiguration-Komponente 6.2 ist derart ausgestaltet, dass die Testkonfiguration immer an die Spezifikation angepasst ist. Beispielsweise wird bei einer Änderung eines Konfigurationsdatums "Bus 5, Message 1 , Position 10" in Bus 5, Message 2, Position 10" die Testkonfiguration automatisch angepasst.
Das Testergebnis enthält einen Test Execution Report und einen Problem Report.
Ein erfindungsgemäßes Verfahren zum Testen von Komponenten und Systemen, weist gemäß Fig. 7 die Verfahrensschritte auf:
Vorbereiten 7.1 eines Tests;
Vorbereiten 7.2 mindestens einer Testkonfiguration;
Ausführen 7.3 des Tests; wobei eine implementierte Testanweisung immer an eine Systemspezifikation angepasst ist und die Testkonfiguration immer an die Gesamtsystemkonfiguration angepasst ist.
In einer Ausführungsform des Verfahrens weist gemäß Fig. 8 der Verfahrensschritt Vorbereiten eines Tests die Unter-Verfahrensschritte auf:
Importieren 8.1 der Systemspezifikation;
Erstellen 8.2 eines Testdesigns;
Erstellen 8.3 von Testfällen;
Erstellen 8.4 mindestens einer Testprozedur.
In einer Ausführungsform des Verfahrens weist gemäß Fig. 9 der Verfahrensschritt Vorbereiten mindestens einer Testkonfiguration die Unter-Verfahrensschritte auf:
Importieren 9.1 der Gesamtsystemkonfiguration;
Prüfen 9.2 der Gesamtsystemkonfiguration:
Erstellen 9.3 der mindestens einen Testkonfiguration.
In einer Ausführungsform des Verfahrens weist gemäß Fig. 10 der Verfahrensschritt Ausführen des Tests die Unter-Verfahrensschritte auf: Laden 10.1 der Testkonfiguration;
Laden 10.2 der Testprozedur;
Ausführen 10.3 des Tests;
Ausgeben 10.4 des Testergebnisses.
Vorzugsweise weist das Verfahren aufgrund der Verfahrensschritte eine Harmonisierung der Gesamtkonfiguration und der Spezifikation auf.
Vorzugsweise weist das Verfahren aufgrund der Verfahrensschritte eine Qualitätssicherung der Eingangsdaten durch Prüfung der Gesamtkonfiguration und der Systemspezifikation auf.
Vorzugsweise weist das Verfahren aufgrund der Verfahrensschritte eine Verfolgbar- keit der Eingangsdaten und erzeugten Daten auf.
Das Verfahren ermöglicht vorteilhaft aufgrund der Verfahrensschritte, jederzeit eine Dokumentation für einen bestimmten Zeitpunkt oder Zeitraum zu erstellen.
Gemäß einer Ausführungsform des Verfahrens in Verbindung mit Fig. 11 ist die Integration der Systemanforderung mittels der folgenden Merkmale bzw. Prozess-Elemente und Verfahren realisierbar:
Importieren 11.1 der Systemanforderungen 4.8 in den Testprozess und Formalisie- rung und Versionierung der Anforderungen mit dem Test execution plan Modul 4.9; zur Verfügung stellen 11.2 von versionierten Systemanforderungen an das Test Design 4.10;
Kennzeichnen 11.3 von Änderungen der Systemanforderungen 4.8 durch neue Importe oder Modifikation Neu, Bearbeiten, Löschen sowie Anzeigen einer Statusänderung bei Test design 4.10;
Reproduzierbarkeit eines Tests gewährleisten 11.4 mittels Versionierung der Testfälle 4.11 und der Tests 4.12.
In einer weiteren Ausführungsform des Verfahrens in Verbindung mit Fig. 12 sind Ressourcen im Testprozess durch folgende Merkmale und Verfahren integriert:
Importieren und Formalisieren 12.1 aller relevanten Prüflinge 4.1 in dem Testsystem 2.5 durch den Goods receipt Modul 4.2 importiert und formalisiert;
Importieren und Formalisieren 12.2 weiterer für den Testaufbau relevanten Softwareelemente Software-Depot, 4.4;
Importieren und Formalisieren 12.3 von Zeichnungen, Verdrahtungen, Komponenten und/oder Simulationen der Testumgebung 4.25;
Zusammenführen 12.4 aller Elemente 4.2, 4.4, 4.5 zu einer Gesamt-Testkonfiguration des Testes und versioniertes Verwalten durch den Resource management Modul 4.3;
Bereitstellen 12.5 des Modul 4.3 für jeden Test und bekannt machen des Modul 4.3 über die SIB-Konfiguration 4.6 dem Testprozess 4.28; Versioniert Definieren 12.6 der Ressourcen-Komponenten 4.3 und Verlinken mit einem Testausführungs-Modul 4.28;
Erleichtern 12.7 der Lokalisierung eines fehlerhaften Verhaltens durch modulare Kapselung der Zusammenhänge und Verbindung durch klare Schnittstellen der Elemente 4.8-4.12, 4.2, 4.3, 4.6, 4.28.
In einer weiteren Ausführungsform des Verfahrens in Verbindung mit Fig. 13 ist eine Signalübersetzung integriert, mit folgenden Merkmalen und Verfahrensweisen:
Importieren 13.1 aller relevanten Schnittstellendefinitionen 4.14 und Formalisieren und Gliedern in der Network configuration 4.15 und in der Signal description 4.16;
Prüfen 13.2 der Schnittstellendefinitionen mittels Correctness check 4.18 auf Konsistenz und Korrektheit;
Zusammenführen 13.3 der Ein-&Ausgangsbeschreibungen 4.19 mit den formalisier- ten Daten Correctness check, 4.18 per Signalmapping 4.17 zu einer Signalkonfiguration 4.14;
Anzeigen 13.4 Status und Speichern der Signalkonfiguration in der SIB-Konfiguration 4.6;
Verbinden 13.5 der gespeicherten Konfigurationen mit dem Testfall 4.11.
Nach einer weiterern Ausführungsform des erfindungsgemäßen Verfahrens sind Testwartbarkeit und Erweiterbarkeit durch folgende Merkmale des Verfahrens vorteilhaft integrierbar:
Testfälle 4.11 werden allgemein gültig entworfen und erst typisiert durch die Verlin- kung mit der SUT-abhängigen Konfiguration der Elemente 4.6 , 4.7. Ändert sich die Konfiguration von 4.6, 4.7 bleibt der Testfall gültig, da die Anpassung in der Konfiguration integriert ist;
Modifikation von vorhandenen Konfigurationen oder Eingabe neuer Konfiguration nur mit einer Skriptänderung der Schnittstellendefinition 4.14 durchführbar;
Grundlegende Änderung der Schnittstellenbeschreibung bzw. Datenbank 4.13 werden nur durch Anpassung der Skripte in den Elementen 4.17 und 4.18 umgesetzt; alle anderen Modulen sind von dieser Änderungen nicht betroffen und bleiben unverändert;
Kommen Funktionalitäten zu einem UUT /SUT 2.2 neu hinzu, erfolgt die Anpassung mit dem gleichen Verfahren. Bezeichnungsliste
1. Signal & mapping
1.1. physikalischer Wert
4.14. Logical mapping / logischer Wert
1.3. Bus typ
2. Umgebungsintegration
2.1. Transducer / Signalgeber
2.2. Unit or System under test /SUT1UUT / Testumgebung / Prüfling
2.3. Test engine
2.4. Repository
2.5. das erfindungsgemäße Testsystem
2.6. Simulation der SUT, UUT / Testumgebung
2.7. Schnittstelle zwischen Simulation und SUT/UUT
2.8. Schnittstelle zwischen generischen Treiber und SUT/UUT
3. Verfolgbarkeit über einen TestprozeßVerfolgbarkeit (Fokus auf Systemrequir.) und Betriebskonfiguration
3.1. Systemrequirements
2.5. das erfindungsgemäße Testsystem
3.3. Controller or Simulation
3.4. Generic driver
3.5. Repository
2.2. Unit or System under test
2.5. das erfindungsgemäße Testsystem / Workstation
4. Prozess: Resourcen, generic driver, Signale, Verfolgbarkeit, Integration, Identifikation, Verfolgbarkeit über einen TestprozeßVerfolgbarkeit, Harmonisierung
2.2. Part (Controller, UUT, SUT,...) / Prüfling
4.2. Goods receipt Modul
4.3. Resource management Modul/ Testeinrichtung / Betriebskonfiguration
4.4. Software Ground Repository / Software-Depot
4.5. Test facility
4.6. SIB konfiguration
4.7. CVS-repository
4.8. System requirements Integration
4.9. Test execution plan Modul / TEP
4.10. Test design Modul /TD
4.11. Test case Modul / TC
4.12. Test procedure Modul / TP / Testschritte 4.13. A/C baseline / Datenbank
4.14. Signal configuration / Konfigurationsdatei/ Schnittstellendefinition
4.15. Network configuration
4.16. Signal description / System-Signale
4.17. Signal & mapping
4.18. Correctness check
4.19. I/O description / Teststand Ein-und Ausgänge
4.20. Failure report
4.21. Test Design Report
4.22. Test case Report
4.23. Problem Report
4.24. Test Report
4.25. Simulation, Komponeten, Hardware, etc.
4.26. Dokumentenmanagementssystem
4.27. Echtteilentwicklungsmanagement
5. das erfindungsgemäße Testsystem Verfahren
5.2. Test item
5.3. Test feature / Funktionen 5.5 Test objective / Testobjekte
5.6. Test requirement
5.7. Depth and Tag
5.8. Test design levels
5.11 TE - Test execution
5.12 Test results
5.13 System requirement verification table
5.14 Signals database (CVS repository)
5.18 Testbench ( from the resource management)
5.19 Compiler / Scriptgenerator
5.20 Script / Ausführbarer Script
6. Testsystem-Komponenten
6.1. Testvorbereitungs-Komponente
6.2. Testkonfigurations-Komponente
6.3. Testausführungs-Komponente
7. Verfahren zum Testen von Komponenten und Systemen
7.1. Vorbereiten eines Tests
7.2. Vorbereiten mindestens einer Testkonfiguration
7.3. Ausführen des Tests 8. Vorbereiten eines Tests
8.1. Importieren der Systemspezifikation
8.2. Erstellen eines Testdesigns
8.3. Erstellen von Testfällen
8.4. Erstellen mindestens einer Testprozedur
9. Vorbereiten mindestens einer Testkonfiguration
9.1. Importieren der Gesamtsystemkonfiguration
9.2. Prüfen der Gesamtsystemkonfiguration
9.3. Erstellen der mindestens einen Testkonfiguration
10. Ausführen des Tests
10.1. Laden der Testkonfiguration
10.2. Laden der Testprozedur
10.3. Ausführen des Tests
10.4. Ausgeben des Testergebnisses
11. Integration der Systemanforderung
11.1. Importieren der Systemanforderungen
11.2. zur Verfügung stellen von versionierten Systemanforderungen
11.3. Kennzeichnen von Änderungen der Systemanforderungen
11.4. Reproduzierbarkeit eines Tests gewährleisten
12. Ressourcen im Testprozess integriert
12.1. Importieren und Formalisieren aller relevanten Prüflinge
12.2. Importieren und Formalisieren weiterer für den Testaufbau relevanten Softwareelemente
12.3. Importieren und Formalisieren von Zeichnungen, Verdrahtungen, Komponenten und/oder Simulationen
12.4. Zusammenführen aller Elemente
12.5. Bereitstellen des Modul für jeden Test
12.6. Versioniert Definieren der Ressourcen-Komponenten und Verlinken
12.7. Erleichtern der Lokalisierung eines fehlerhaften Verhaltens
13. Signalübersetzung
13.1. Importieren aller relevanten Schnittstellendefinitionen 4.14 und Formalisieren und Gliedern
13.2. Prüfen der Schnittstellendefinitionen
13.3. Zusammenführen der Ein-&Ausgangsbeschreibungen
13.4. Anzeigen Status und Speichern
13.5. Verbinden der gespeicherten Konfigurationen mit dem Testfall

Claims

Patentansprüche
1. Testanordnung zum Testen von Komponenten und Systemen mit einem Testsystem, welches Schnittstellen zum Anschluss eines Unit Under Test (UUT) aufweist, einer Steuereinheit zur Ansteuerung des Testsystems, einer Datenbank, welche Daten über Komponenten- und/oder Systemrequirements des UUT und Daten über einen Test aufweist, dadurch gekennzeichnet, dass das Testsystem folgende Testsystem- Komponenten aufweist: eine Testvorbereitungs-Komponente (6.1 ), die als Input eine Systemspezifikation erhält, diese Systemspezifikation zu einer implementierten Testanweisung aufbereitet, und diese implementierte Testanweisung ausgibt; eine Testkonfigurations-Komponente (6.2), die als Input eine Baseline für eine Gesamtsystemkonfiguration erhält, diese Baseline zu einer Testkonfiguration aufbereitet, und diese Testkonfiguration ausgibt; eine Testausführungs-Komponente (6.3), die als Input unter anderem die implementierte Testanweisung und die Testkonfiguration erhält, diese ausführt und das Testergebnis ausgibt.
2. Testanordnung nach Anspruch 1 , dadurch gekennzeichnet, dass die Testvorbereitungs-Komponente (6.1 ) derart ausgestaltet ist, dass die implementierte Testanweisung immer an die Systemspezifikation angepasst ist.
3. Testanordnung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Testkonfiguration-Komponente (6.2) derart ausgestaltet ist, dass die Testkonfiguration immer an die Gesamtsystemkonfiguration angepasst ist.
4. Testanordnung nach einem der vorhergehenden Ansprüche, , dadurch gekennzeichnet, dass die Testanordnung weiterhin eine Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur aufweist.
5. Testanordnung von Komponenten und Systemen nach Anspruch 4, dadurch gekennzeichnet, dass die Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur ein Modul zum Erstellen eines Test Execution Plan aufweist.
6. Testanordnung von Komponenten und Systemen nach einem der Ansprüche 4 oder 5, dadurch gekennzeichnet, dass die Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur ein Modul zur Spezifikation der Testanordnung und des UUT aufweist.
7. Testanordnung von Komponenten und Systemen nach einem der Ansprüche 4 bis 6, dadurch gekennzeichnet, dass die Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur ein Modul zum Erstellen eines Test Design aufweist.
8. Testanordnung von Komponenten und Systemen nach einem der Ansprüche 4 bis 7, dadurch gekennzeichnet, dass die Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur ein Modul zum Erstellen von Test Cases aufweist.
9. Testanordnung von Komponenten und Systemen nach einem der Ansprüche 4 bis 8, dadurch gekennzeichnet, dass die Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur ein Modul zum Erstellen von Test Scripten aufweist.
10. Testanordnung von Komponenten und Systemen nach einem der Ansprüche 8 bis 9, dadurch gekennzeichnet, dass die Einrichtung zur Assistenz bei dem Erstellen einer Test-Prozedur ein Modul zum Erstellen eines Test Execution Plan unter Verwendung der Test cases aufweist.
11. Verfahren zum Testen von Komponenten und Systemen, gekennzeichnet durch die Verfahrensschritte:
- Vorbereiten (7.1 ) eines Tests;
- Vorbereiten (7.2) mindestens einer Testkonfiguration;
- Ausführen (7.3) des Tests; wobei eine implementierte Testanweisung immer an eine Systemspezifikation angepasst ist und die Testkonfiguration immer an die Gesamtsystemkonfiguration angepasst ist.
12. Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass der Verfahrensschritt Vorbereiten eines Tests die Unter-Verfahrensschritte aufweist:
- Importieren (8.1 ) der Systemspezifikation;
- Erstellen (8.2) eines Testdesigns;
- Erstellen (8.3) von Testfällen;
- Erstellen (8.4) mindestens einer Testprozedur.
13. Verfahren nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass der Verfahrensschritt Vorbereiten mindestens einer Testkonfiguration die Unter-Verfahrensschritte aufweist:
- Importieren (9.1) der Gesamtsystemkonfiguration;
- Prüfen (9.2) der Gesamtsystemkonfiguration:
- Erstellen (9.3) der mindestens einen Testkonfiguration.
14. Verfahren nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, dass der Verfahrensschritt Ausführen des Tests die Unter-Verfahrensschritte aufweist:
- Laden (10.1) der Testkonfiguration;
- Laden (10.2) der Testprozedur;
- Ausführen (10.3) des Tests;
- Ausgeben (10.4) des Testergebnisses.
15. Verfahren nach einem der Ansprüche 11 bis 14, dadurch gekennzeichnet, dass das Verfahren aufgrund der Verfahrensschritte eine Harmonisierung der Gesamtkonfiguration und der Spezifikation aufweist.
16. Verfahren nach einem der Ansprüche 11 bis 15, dadurch gekennzeichnet, dass das Verfahren aufgrund der Verfahrensschritte eine Qualitätssicherung der Eingangsdaten durch Prüfung der Gesamtkonfiguration und der Systemspezifikation aufweist.
17. Verfahren nach einem der Ansprüche 11 bis 16, dadurch gekennzeichnet, dass das Verfahren aufgrund der Verfahrensschritte eine Verfolgbarkeit der Eingangsdaten und erzeugten Daten aufweist.
18. Verfahren nach einem der Ansprüche 11 bis 17, dadurch gekennzeichnet, dass das Verfahren aufgrund der Verfahrensschritte ermöglicht, jederzeit eine Dokumentation für einen bestimmten Zeitpunkt oder Zeitraum zu erstellen.
19. Verfahren nach einem der Ansprüche 11 bis 18, dadurch gekennzeichnet, dass die Integration der Systemanforderung mittels der folgenden Merkmale bzw. Prozess-Elemente und Verfahren realisierbar ist:
Importieren (11.1 ) der Systemanforderungen (4.8) in den Testprozess und Formali- sierung und Versionierung der Anforderungen mit dem Test execution plan Modul (4.9); - zur Verfügung stellen (11.2) von versionierten Systemanforderungen an das Test Design (4.10);
Kennzeichnen (1 1.3) von Änderungen der Systemanforderungen (4.8) durch neue Importe oder Modifikation (Neu, Bearbeiten, Löschen) sowie Anzeigen einer Statusänderung bei Test design (4.10);
Reproduzierbarkeit eines Tests gewährleisten (11.4) mittels Versionierung der Testfälle (4.11) und der Tests (4.12).
20. Verfahren nach einem der Ansprüche 11 bis 19, dadurch gekennzeichnet, dass Ressourcen im Testprozess durch folgende Merkmale und Verfahren integriert sind: Importieren und Formalisieren (12.1) aller relevanten Prüflinge (4.1) in dem Testsystem (2.5) durch den Goods receipt Modul (4.2) importiert und formalisiert; Importieren und Formalisieren (12.2) weiterer für den Testaufbau relevanten Softwareelemente (Software-Depot, 4.4);
Importieren und Formalisieren (12.3) von Zeichnungen, Verdrahtungen, Komponenten und/oder Simulationen der Testumgebung (4.25);
- Zusammenführen (12.4) aller Elemente (4.2, 4.4, 4.5) zu einer Gesamt- Testkonfiguration des Testes und versioniertes Verwalten durch den Resource ma- nagement Modul (4.3);
Bereitstellen (12.5) des Modul (4.3) für jeden Test und bekannt machen des Modul (4.3) über die SIB-Konfiguration (4.6) dem Testprozess (4.28); Versioniert Definieren (12.6) der Ressourcen-Komponenten (4.3) und Verlinken mit einem Testausführungs-Modul (4.28);
Erleichtern (12.7) der Lokalisierung eines fehlerhaften Verhaltens durch modulare Kapselung der Zusammenhänge und Verbindung durch klare Schnittstellen der Elemente 4.8-4.12, 4.2, 4.3, 4.6, 4.28.
21. Verfahren nach einem der Ansprüche 11 bis 20, dadurch gekennzeichnet, dass eine Signalübersetzung integriert ist, mit folgenden Merkmalen und Verfahrensweisen:
Importieren (13.1) aller relevanten Schnittstellendefinitionen (4.14) und Formalisieren und Gliedern in der Network configuration (4.15) und in der Signal description (4.16); Prüfen (13.2) der Schnittstellendefinitionen mittels Correctness check (4.18) auf Konsistenz und Korrektheit;
- Zusammenführen (13.3) der Ein-&Ausgangsbeschreibungen (4.19) mit den formali- sierten Daten (Correctness check, 4.18) per Signalmapping (4.17) zu einer Signalkonfiguration (4.14); Anzeigen (13.4) (Status) und Speichern der Signalkonfiguration in der SlB- Konfiguration (4.6); - Verbinden (13.5) der gespeicherten Konfigurationen mit dem Testfall (4.11).
22. Verfahren nach einem der Ansprüche 11 bis 21 , dadurch gekennzeichnet, dass Testwartbarkeit und Erweiterbarkeit durch folgende Merkmale des Verfahrens integrierbar sind:
Testfälle (4.11) werden allgemein gültig entworfen und erst typisiert durch die Verlin- kung mit der SUT-abhängigen Konfiguration der Elemente 4.6 , 4.7. Ändert sich die Konfiguration von 4.6, 4.7 bleibt der Testfall gültig, da die Anpassung in der Konfiguration integriert ist;
Modifikation von vorhandenen Konfigurationen oder Eingabe neuer Konfiguration nur mit einer Skriptänderung der Schnittstellendefinition (4.14) durchführbar; Grundlegende Änderung der Schnittstellenbeschreibung bzw. Datenbank (4.13) werden nur durch Anpassung der Skripte in den Elementen 4.17 und 4.18 umgesetzt; alle anderen Modulen sind von dieser Änderungen nicht betroffen und bleiben unverändert;
Kommen Funktionalitäten zu einem LJUT /SUT (2.2) neu hinzu, erfolgt die Anpassung mit dem gleichen Verfahren.
PCT/EP2005/014087 2004-12-23 2005-12-23 Vorrichtung und verfahren zum testen von komponenten und systemen WO2006081869A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004063092 2004-12-23
DE102004063092.5 2004-12-23

Publications (1)

Publication Number Publication Date
WO2006081869A1 true WO2006081869A1 (de) 2006-08-10

Family

ID=36123325

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/014087 WO2006081869A1 (de) 2004-12-23 2005-12-23 Vorrichtung und verfahren zum testen von komponenten und systemen

Country Status (1)

Country Link
WO (1) WO2006081869A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009000822A1 (de) * 2007-06-25 2008-12-31 Airbus Operations Gmbh Testsystem-verbund zum parallelen testen mehrerer systeme unter test mit mehreren testsystemen
EP2866111A1 (de) * 2013-10-28 2015-04-29 dSPACE digital signal processing and control engineering GmbH Testen eines Steuergerätes mittels einer Testumgebung
CN113157515A (zh) * 2021-05-25 2021-07-23 西安超越申泰信息科技有限公司 飞腾平台fpga加速卡引入测试方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020073375A1 (en) * 1997-06-03 2002-06-13 Yoav Hollander Method and apparatus for test generation during circuit design
US20040225459A1 (en) * 2003-02-14 2004-11-11 Advantest Corporation Method and structure to develop a test program for semiconductor integrated circuits

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020073375A1 (en) * 1997-06-03 2002-06-13 Yoav Hollander Method and apparatus for test generation during circuit design
US20040225459A1 (en) * 2003-02-14 2004-11-11 Advantest Corporation Method and structure to develop a test program for semiconductor integrated circuits

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009000822A1 (de) * 2007-06-25 2008-12-31 Airbus Operations Gmbh Testsystem-verbund zum parallelen testen mehrerer systeme unter test mit mehreren testsystemen
US8874421B2 (en) 2007-06-25 2014-10-28 Airbus Operations Gmbh Test system combination for testing several systems under test in parallel, comprising several test systems
EP2866111A1 (de) * 2013-10-28 2015-04-29 dSPACE digital signal processing and control engineering GmbH Testen eines Steuergerätes mittels einer Testumgebung
CN104572370A (zh) * 2013-10-28 2015-04-29 帝斯贝思数字信号处理和控制工程有限公司 用于借助测试环境测试控制器的系统和方法
US9626263B2 (en) 2013-10-28 2017-04-18 Dspace Digital Signal Processing And Control Engineering Gmbh Testing a control unit by means of a test environment
CN104572370B (zh) * 2013-10-28 2019-07-05 帝斯贝思数字信号处理和控制工程有限公司 用于借助测试环境测试控制器的系统和方法
CN113157515A (zh) * 2021-05-25 2021-07-23 西安超越申泰信息科技有限公司 飞腾平台fpga加速卡引入测试方法及系统

Similar Documents

Publication Publication Date Title
EP2685382B1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
EP2244141B1 (de) Verfahren und Vorrichtung zur Verifizierung eines Automatisierungssystems
DE102009059865B4 (de) Integriertes Testsystem und Verfahren zur Bewertung eines Fertigungsautomatisierungssystems
US20090019311A1 (en) Method of testing an electronic system
DE60031384T2 (de) Test-und simulationssysteme
EP1428126A2 (de) Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem
DE102017211433B4 (de) Verfahren zum Durchführen eines Funktionstests eines Steuergeräts in einem Hardware-in-the-Loop-Test, HIL-Test, sowie HIL-Prüfstand und Steuergerät
EP3650970B1 (de) Verfahren und vorrichtung zum computergestützten simulieren eines modularen technischen systems
EP3379351B1 (de) Verfahren zum betreiben einer automatisierungseinrichtung sowie automatisierungseinrichtung
DE102017120016A1 (de) Verfahren zur Konfiguration eines zum Testen eines elektronischen Steuergeräts eingerichteten Testgeräts sowie Konfigurationssystem
EP3832517A1 (de) Computerimplementiertes verfahren zur einbindung mindestens eines signalwerts in einem virtuellen steuergerät
EP3979009A1 (de) Erzeugen eines vereinfachten modells für xil-systeme
DE102021004346A1 (de) Verfahren zum Aufbau und zur Pflege einer Fahrzeugtypbibliothek
WO2006081869A1 (de) Vorrichtung und verfahren zum testen von komponenten und systemen
EP2492701B1 (de) Verfahren und Vorrichtung zum Testen einer Windturbinenanlage
DE112021003677T5 (de) Automatisierte unterstützte schaltkreisvalidierung
DE102012015363B4 (de) Vorrichtung zur Ermittlung von Fehlern eines zum Tragflug an einem Trägerflugzeug ausgebildeten unbemannten Flugkörpers und Verfahren dazu
EP1866715B1 (de) Entwurfsvorrichtung zum entwerfen einer leittechnischen anlage und verfahren zum überprüfen der technologischen aufgabenstellung beim entwurf einer leittechnischen anlage
DE102007019201B4 (de) Abgleichen von Daten eines Steuer- und/oder Datenübertragungssystems und eines dieses repräsentierenden Systemmodells
DE112019006528T5 (de) Echtzeit-Kommunizierendes Fahrzeugsimulationssystem und dessen Verfahren
WO2006035038A2 (de) Verfahren zum testen von steuergerätesoftware für ein steuergerät
DE19751273A1 (de) Verfahren zum computergestützten Erstellen und Handhaben einer auf Produkt- oder Prozesslebenszyklen bezugnehmenden technischen Datenbank
DE102006015207A1 (de) Verfahren und Vorrichtung zur Entwicklung eines Systems für die Betriebsdiagnostik von Fahrzeugen
EP1632855A1 (de) Funktionseinheit zur Ausführung von logischen Testfällen auf einem an eine zu prüfende Einheit angekoppelten Testsystem und entsprechendes Verfahren
EP4092535B1 (de) Verfahren zum testen von steuergeräten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase

Ref document number: 05821781

Country of ref document: EP

Kind code of ref document: A1