Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/36—Preventing errors by testing or debugging software
  • G06F11/3664—Environments for testing or debugging software

Definitions

• the present invention relates to a method for producing a durable universal tool for developing equipment tests and to a tool for implementing this method.
• test bench The development of a test bench is similar to the development of an operational system with its constraints, obsolescence issues, traceability and re-use requirements.
• the present invention relates to a method of producing a test bench for the development of a test program at the lowest possible cost. It also relates to a test bench made according to this method.
• the method according to the invention is a method for producing a durable universal tool for developing equipment test programs using a test bench, and it is characterized in that it comprises the steps following, implemented with a test development tool comprising a calculator, information acquisition and visualization means and at least one memory: an operator designs the various tasks and sub-tasks of the test program on a test bench that the tool memorizes, - it enters the specifications of the requirements of the test program, it chooses the requirements of the scenario to be followed according to the results of the test, when the operator has entered the information relating to the tests, the tool automatically generates the documentation for the tests thus designed, then a development operator describes the procedure for each of the tests whose requirements have been formulated using the commands provided by a library of generic commands of the tool, the operator proceeds to the design of each elementary test, the tool automatically generates an exportable file translated into a language appropriate to the test bench used during tests.
• a test development tool comprising a calculator, information acquisition and visualization means and at least one memory: an operator designs the various tasks and sub-
• FIG. 1 is a block diagram of an example embodiments of a test development tool implementing the method of the invention
• FIGS. 2 to 7 are examples of screen views taken at different stages of implementation of the process design steps in accordance with FIG.
• FIG. 8 is a screen view of an exemplary document corresponding to the specification of the test requirements
• FIG. 9 is a screen view of an exemplary test flow chart such as can be produced according to the method of the invention
• FIGS. 10 to 12 are examples of screen views taken at different stages of implementation of the test design steps according to the method according to the present invention
• FIG. 13 is a diagram serving to explain the generation, according to the method of the invention, of a test code that can be used by a test bench.
• the method of the invention is essentially characterized by the establishment of a tool ensuring a real link between the test specification and the code, and it makes it possible to optimize the phases of specification, design and coding of a program of test.
• FIG. 1 shows an exemplary embodiment of a universal and durable tool 1 for developing equipment tests implementing the method of the invention.
• This tool 1 comprises a function 2 of data entry.
• This function is used to enter the specifications of the requirements relating to the tests to be carried out, and in particular the definition of the tree of these tests in "GO" and “NO GO” modes, that is to say in BON or Binary mode. BAD and tolerances applicable to the results of these tests.
• This function 2 is connected to a requirements generation engine 3 producing documentation relating to the specification of the software test requirements, specification corresponding to a particular formatting (4), and is followed by a function 5 of test design.
• the function 5 consists in particular of defining entry conditions making it possible to meet the requirements relating to the tests to be performed. The implementation of functions 2 and 5 is explained in detail below with reference to FIGS. 2 to 7.
• the function 5 is connected to a test generation engine 6 of a type known per se, producing documentation 7 exposing the test procedures designed using the function 5, and possibly the documentation 8 exposing the validation processes. product tests and documentation intended to record the results of this validation.
• the function 5 is connected to a motor 9 producing a test flow chart 10, and is connected to a pre-existing generic command library 11.
• This library 11 is in turn linked to specific language libraries.
• two specific language libraries for example the "Labview” language library 12 producing 12A test codes in "Labview” language and the "ATEasy” language library 13 producing 13A test codes in "ATEasy” language, but it is understood that the tool 1 may comprise a single library of test language codes or one or more other libraries producing test program codes appropriate to the test benches used with the tool 1 of the invention in the present or in the future.
• the tests must be carried out on equipment throughout their lifetime, which may exceed 20 years, with test benches whose test programs are usually renewed or modified after a much shorter period of time. the service life of the equipment to be tested. Thanks to the invention, it is possible to keep (in the memory of the calculator of the tool 1 and / or on removable storage media) a trace of the test protocols and of the way in which they were designed at least as long as the materials to be tested are used. Due to the modularity of the tool 1 (libraries 12 and 13 independent of the other functions of the tool 1), it is sufficient to change the code library (library such as 12 or 13) to adapt it immediately to a new one. test language.
• FIGS. 2 to 7, described below, relate to screen views of a display terminal of a computer, such as a microcomputer, used by an operator (which is, in this first phase requirements specification, the equipment specialist to be tested) to perform the requirements of the test program requirements and incorporating the tool 1.
• a computer such as a microcomputer
• Fig. 2 shows a screen view 14 opening to the launch of the requirements specification PSE process of tool 1 (function X).
• This screen displays, in the present example, four different windows referenced 15 to 18, the window 17 having three "sub-windows" 19 to 21. These windows are respectively the following:
• Window 15 Main window to display the various tasks and sub-tasks of the test program, used later on a test bench, as they are designed. When launching the PSE program, this window contains only an initial line "PROGRAM WITHOUT TITLE ", which will be completed by a first operator who is here the operator of specification of the requirements of the PSE process during the implementation of this process.
• Window 16 initially labeled "PROGRAM WITHOUT TITLE", as the only line of the window 15, and having, in the present example, four tabs: "Description” (activated here), “Properties”, “Jump at the end of the test Vi And “Jump at the end of the test 2/2".
• this window 16 there is a caption "You can put a description here", in order to put a description of the program.
• - Window 17 entitled “List of orders”. It initially comprises, in the pane 19, two lines: “PROGRAM” and “SYSTEM”. Its other two sub-windows 20 ("Parameter”) and 21 (“Value") are initially empty.
• the window 17 has three buttons 22 to 24. These three buttons are titled respectively "Create Macro", “Delete Macro” and "Add”.
• Window 18 In fact, it looks like a tab, titled “Select a test ". Initially, it is not activated, because there is still no test.
• the view 14 also includes a set of buttons.
• This set of buttons includes buttons with conventional symbols such as “Open Folder”, “Save”, “Cut”, etc., as well as some buttons that are specific to the invention, such as that used in the example illustrated in FIG. figure 13.
• the view 26 of Figure 3 shows the beginning of the entry phase of the tasks and sub-tasks of the PSE process.
• information 27 has been entered only in window 15.
• the test program is now called “TEST OF MY EQUIPMENT”.
• This program has several tasks, called here "POWER FUNCTION”, “PRE AMP FUNCTION”, etc. These tasks consist of subtasks.
• the power function has subtasks such as "AREA TEST”, “TEST VOLTAGE”, and so on.
• the view 28 of Figure 4 shows the details of a subtask.
• this subtask is "TEST -24V" which has been activated by clicking on the corresponding line of window 15.
• the name of this subtask is then displayed as the title of windows 16 and 18.
• various commands that can be integrated in the "TEST -24V" are displayed.
• the window 16 displays the description, written by the operator, of the activated test in question.
• the first data entry step consists in having the operator enter, for each selected elementary test, the associated requirements, such as type of measurement, units of measurement, applicable tolerances. measured values to recognize them as good, etc.
• the operator activates the "Properties” tab of the window 16 relating, in the present example, to the test "TEST -24V".
• the different properties which are selected in sub-windows, are: "Min / Max” for the type, "J2-21” for the name of the voltage measurement point, "V" (for Volts ") For the unit of measurement, -25 for the minimum tolerable value of the measured voltage to recognize it as good, and -23 for the maximum permissible value.
• the strip shown at the very bottom of the view of this FIG. 5 (as well as in FIGS. 3 and 4 and FIGS. 6, 7, 10 and 11) provides additional indications such as the level of the test in the program tree. test, the index associated with this test, the identity of the test and the time.
• the tool 1 is able to automatically generate a document (printed document, for example as document 4 of Figure 1, or a document viewed on a screen, such as that of Figure 8) corresponding to the specification of the test requirements.
• This document is for example of the type partially shown in Figure 8, and possibly any other type of document using the information entered by the first operator.
• These other documents thus generated are, for example, documents describing various phases of the requirements design, validation procedures, etc.
• the left portion of the view of Figure 8 shows some of the first pages of the specification of the test requirements.
• the right part of the view 31 of Figure 8 shows the detail of a selected page in the left part, and in this case page 8 has been selected.
• FIG. 9 shows an exemplary test scenario flow chart 32, such as that of document 10 of FIG.
• a development operator (who may be the first operator or a programmer) describes the procedure for each of the tests whose requirements have been formulated by the first operator. For this purpose, it uses the commands provided by the library of the tool, which is the library 11 of generic commands illustrated in FIG. 1. In the sub-window 19 of the view 33 of FIG. generic commands, which are available for all tests, and in this case, those relating to the test "TEST + 24V" and referenced 34 in this figure.
• the operator proceeds to the design of each elementary test.
• the operator chooses in the sub-window 19 (view 35 of FIG. 11) the command "(measure) a DC voltage”.
• the sub-windows 20 and 21 indicate for this command the corresponding parameters.
• this is the display parameter of the result of the voltage measurement (+ 24V).
• This parameter is simply called “RESULT” and its value is the variable “result” which represents the result of the measurement performed by activating the DC voltage subtask (appearing in window 19).
• the window 16 displays the corresponding comment "Test of the presence of the + 24V at the J2-19 point of the power supply" in the "Description" tab.
• the "TEST + 24V" tab of the window 18 displays, in so-called “high level” language, the different lines of the corresponding program, whose names of the routines visible on the drawing are successively: “operator preparation”, “Implementation mains route ", automatic connection to J2-19” and "Voltage measurement + 24V".
• routines that can be called at any time.
• a routine macro-command
• SECTOR BREAK which can be called several times during the design of the program, was created for this purpose and is accessible from an additional tab of the window 18 called "COUPURE_S ECTEUR”. By clicking on this tab, the operator brings up this routine.
• This routine is insertable into the program:
• Tool 1 automatically generates an exportable file translated into an appropriate language.
• test bench used during the tests for example one of the two available languages of the tool of FIG. 1, namely "ATEasy” and "Labview”.
• the tool of the invention makes it possible, from the data entered by the user, to automatically generate documentation and code (with choice of the language used).
• the links and the traceability (obtained thanks to the memorization of all the test requirements and the different parameters and test procedures in the tool 1), deployed through the various development phases, also make it possible to ensure quality of the output product.
• the architecture of the tool associated with the architecture of the development process, allows a maximum re-use that does not become obsolete over time.
• the tool was developed initially using 'Excel' then in 'cSharp' language.
• test program it allows any operator to specify the test program: to specify easily and structurally its test requirements (provision of a test specification method, see figures 2 to
• CMMI2 the readability of the programs obtained: clear and comprehensible information (in "high level” language, as specified above), thus guaranteeing their durability.
• a tool according to the invention is universal in the world of testing and measurement, it is absolutely not related to an existing product.
• a tool according to the invention is not a test sequencer. However, as in any equipment test procedure, the architecture to be respected for obtaining a final output product is notified: an automated equipment test program, development documentation, validation, etc.
• a tool according to the invention is perennial because it is not associated with an existing equipment test language or application. On the contrary, a test sequencer is associated with marketed, often proprietary applications, which can lead to significant obsolescence and non-sustainability.
• a tool according to the invention is oriented equipment test but is de-correlated to an existing test bench, equipped with measuring instruments and responsible for an existing test application, with integrated sequencer or not. It is used on a simple PC. Its output products, development documentation, support, validation and equipment testing procedures, are completely independent of, and transportable to, any type of existing or future applications or languages. The independence of the output products at the origin of the criteria "universal” and “perennial".
• the invention makes it possible to carry out an equipment test procedure according to the required architecture of any test program.
• the invention enables the operator to design his various tasks and sub-tasks of his equipment test procedure, outside the test bench.
• the tool memorizes its procedure and allows the export of this procedure on a test bench equipped, whatever the application, the sequencer used or the code used.
• the invention makes it possible to specify at a higher level the test procedure.
• the most immediate effect is that it is capable of producing a specification document, a specification document, which records all the expected requirements of the equipment test, produces a test procedure and a posteriori, a program equipment test to wear on a bench.
• These specifications include: requirements on the output product's capacities: test program, functions tested by the equipment test procedure, - the independence of the sub-modules thus designed , internal and external interface requirements with the output program, requirements on sizing and processing time, safety and security requirements, design constraints, specific performance related to the output test program, the different operating modes around the course of the procedure , coverage rates and associated location rates, ... and finally detailed requirements on the tasks and to be produced, giving the contractual aspect necessary for the development and validation of the output product.
• the invention thus allows the entry of all the requirements associated with the test procedure and their traceability, at the same time as the entry of the unit tests.
• the method according to the invention gives, from the engineering of an equipment test procedure and outside the defined sequencer and bench, the capacity, and the novelty in the field, of defining the scenario requirements of the test procedure at produce. These requirements entered in the tool are independent of any bench or any sequencer. What makes it special, its strength of universality and translates a technological leap from what exists today on the market. Today, commercial competition forces manufacturers to offer proprietary products that are therefore competing and non-universal.
• the invention provides a library of generic commands.
• This library always on the aspect "universality and durability”, brings a technological leap over the prior art or there are no generic commands to specify its equipment testing procedure, universally, but rather to directly produce low-level code according to pre-defined software test writings in the world of instrumentation.
• the invention differs from those applications of the prior art.
• the output product can then be applied to any test platform equipment, from one supplier or another.
• One of the objectives of the tool is to architect a test procedure, regardless of the platform to use.
• Today the choice of the platform is a real dilemma for manufacturers. They are forced to make a choice between the different platforms available and then take the risk of ensuring themselves successive obsolescence.
• the invention makes it possible, from the universal test procedure of a device, specified, designed and documented from the same tool, to export to a language chosen a posteriori, the final code, equipment test program, operating on the desired platform.
• a database coupled to the tool is responsible for automatically generating the code, low level. This has a double advantage: no knowledge of computers and equipment-oriented languages, possible porting of test engineering from one language to another, present or future, in the event of language and / or platform obsolescence.
• a tool according to the invention therefore automatically generates, according to the chosen language, a directly executable file on the host test bench.
• the tool allows to generate again, from the same source, a file in a different language.
• the steps of the method according to the invention make it possible in particular to describe the genericity, the durability, the ease of obsolescence processing engineering work performed on a tool object of the invention.
• the invention is easy to implement, the use of a simple PC by a non-specialist software, while in existing solutions must have chosen and be equipped with a test platform , to have competent resources on the languages available on the market, and especially to have at its disposal the test bench for engineering and development, expensive.
• the universal aspect of a tool according to the invention is translated by the fact that: the engineering and development work is carried out outside any pre-defined solutions, the documentation type output products are universal, not processing not of a platform or a language proprietary, thus totally sustainable and transportable on different environments, the products of exit type procedures of test of equipment, are exportable whatever the code and on any type of application, thanks to the generic / specific conversion databases of the tool. Contrary to the prior art, the invention makes it possible to specify a test, at the true level of a specification, and thus a high level, and not by directly writing the low level output code.
• the invention also makes it possible to automatically generate all the documentation for development, specification, design, test, validation, ... in the industrial standard format DOD XX, depending on the data and the input form that the tool imposes.
• the invention guarantees in particular: a complete engineering tool, from the high-level specification of the test procedure, to the production of all the development documents related to the industrial development cycle, referred to as V, of a universal language, therefore durable, designed to be transportable to any type of current or future equipment test language.
• a tool according to the invention is put in the hands of the equipment specialist to be tested. From there is produced all the documentation and the test procedure in a totally generic script. The procedure is used to generate the code in a test language chosen a posteriori, existing or future. Any evolution of the engineering thus made is automatically taken into account by the tool, documentation of the language.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Hardware Design (AREA)
• Quality & Reliability (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=39564570

Family Applications (1)

Country Status (4)

Families Citing this family (3)

Family Cites Families (8)

• 2007
  • 2007-12-28 FR FR0709176A patent/FR2925966B1/fr active Active
• 2008
  • 2008-12-24 US US12/810,854 patent/US20100287415A1/en not_active Abandoned
  • 2008-12-24 EP EP08867542A patent/EP2225641A1/de not_active Withdrawn
  • 2008-12-24 WO PCT/EP2008/068295 patent/WO2009083574A1/fr active Application Filing

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events