FR2716059A1 - Parameter management device e.g. for large=scale communication network with modems - Google Patents

Abstract

The device includes a principal management device (40) which is connected to the output of a processor. The principal management device includes a hard disk storage memory (41) and input/output terminals. A transmitter (45) receives information describing the control parameters and emits information describing modification of the parameters. The device which introduces the data into the system cooperates with the transmitter and receives the parameter configuration data in a file created on the hard disk. The parameter configuration data files are input to a database. The database is modified by an intermediate input/output device and the data files are then used in a control circuit.

Description

DEVICE FOR ADJUSTING THE PARAMETERS OF A LARGE SYSTEM.

Description
The present invention relates to a device for managing the parameters of a large system formed of different elements provided with circuits having adjustment parameters to be managed, device comprising: a main management member formed from a processor to which are attached - a mass storage device and input-output devices, - a transmission device for receiving the information describing the parameters to be adjusted and for transmitting the information describing the parameters to be modified, all by means of the system,
Such a device finds important applications, in particular in the field of telecommunications networks where the different elements are data switches linked together by means of modems.

With this kind of systems, there are a very large number of parameters to adjust and lton is confronted with the problem of this large number and also with the interdependence of these.

In the application envisaged above, this type of work falls to the management centers. A known management center is described on pages 11 to 19 in the article: "X25
Network management system.n published in the review: "Philips
Telecommunication Revient1, Ne 4 of December 1990.

 This article gives no details as to how the adjustment task is carried out.

 The present invention provides a device of the kind mentioned in the preamble which is well suited to the settings of devices of any type with few modifications.

 For this, the present invention is remarkable in that the device for managing the adjustment parameters of a large system comprises - import means cooperating with the transmission member, to receive, in a configuration file created in the 'mass memory device, parameters of a circuit to be set, - means for transcribing configuration files into database files, - means for modifying databases via input devices -output, - means for transcribing the modified database files into modified configuration files - and repatriation means cooperating with the transmission member, for (tele) loading the configuration files to the circuit to be adjusted.

 The following description given with reference to the attached drawings, all given by way of nonlimiting example, will make it clear how the invention can be implemented.

 Figure 1 shows a network to configure.

Figure 2 shows a switching device and a modem
being part of the network to be configured.

 Figure 3 shows a diagram of the device of the invention.

Figure 4 shows the tree structure of the managed database
by the device of the invention.

Figure 5 shows the appearance of a screen appearing on
the display device of the device of the invention.

 In Figure 1, a network 1 is shown. It is formed by different switching elements 5, 6, 7, 8, 9 and 10. These elements can, for example, be of the type described in the article entitled "New architecture for the Compac range" published in number 3 of the review Commutation & Transmission of 1992. These different switching bodies are linked together by links 20, 21, 22, 23, 24, 25 and 26, these links respectively connecting bodies 5 and 7, 6 and 7, 6 and 10, 5 and 10, 8 and 10, 6 and 9 and 8 and 9. In principle, connections involve the presence of modems. For reasons of simplicity, only four have been shown: 31, 32, 33 and 34 of which the first two are attached to member 9 and the last two, respectively to switching members 6 and 8.

 To modify or initialize the parameters of all these remote devices, that is to say the various switching devices or modems, use is made of a device 40 constituted around a computer of the PC type comprising the usual elements: device display, keyboard, etc. For the explanation of the implementation of the invention, the hard disk 41 and the link circuit 45 (a modem) which connects the device 50 to the network 1 via the member have been isolated. switching 5.

 To clearly show the interest of the invention, for the operation of complex systems, the structure of a switching member is explained below.

 FIG. 2 schematically shows part of the switching member 6 and the modem 33 which is attached to it. It goes without saying that the other switching members can have the same structure. The switching member 6 is formed by four microcontrollers 51, 52, 53 and 54 grouped as master-slave (51 and 53 are masters and 52 and 54 are their respective slaves); these microprocessors are 68302 manufactured by "MOTOROLA" (registered trademark). Each of these processors has three communication ports which are used as switching access A1 to A6, B1 to B6. Access A1, A2 and A3 are linked to microprocessor 51, A4, A5 and A6 to microprocessor 52, access B1, B2 and B3 to microprocessor 53 and access B4, B5 and B6 to microprocessor 54. These different microprocessors operate in common at least a first memory 61 and a second memory 62. In the first memory are written operating programs which can, among other things, process the routing of the different data to said accesses A1, .., A6, B1, .., 136. In the second memory of the EEPROM type are written the various parameters capable of being modified or initialized by the device of the invention. An arbitration circuit 65 authorizes access to the memories 61 and 62 for the master-slave couple 51 and 52 or for the couple 53 and 54. This arbitration circuit has been described in French patent application N 2 667 175 filed September 25, 1990 in the name of the plaintiff. The information to be switched can also be directed to other parts of the structure member identical to that shown in this FIG. 3, for example via links 71 and 72; for this, a controller 80 of the type known under the name of transputer is used, for example T222, manufactured by "INMOS" (registered trademark). A switching memory 85 is used to allow the exchange of data between the microprocessors 51, 52, 53, 54 and 80. The accesses to this common switching memory 85 are regulated by another arbitration circuit 88. The modem 33 is connected to access B6 via an interface circuit 90 which provides a connection that respects, for example, the CCITT V24 protocol The number of parameters of a switching device is estimated at 30,000, while this number is of the order of a few hundred for modems.

The parameters contained in the memory 62 are of binary form, so that the microprocessors 51 to 54 can process them directly whereas the parameters of the modems are presented in ASCII form to indicate commands of the HAYES type. These HAYES type commands are interpreted by the modem when signals from the interface 90 force it to accept these HAYES commands. On this subject, one can consult French patent application No. 2 687 877 of March 2, 1993 in the name of the applicant.

 FIG. 3 is a diagram which shows the organization of the device 40 in accordance with the invention. This device is built around a PC-like computer compatible. The reference 100 indicates the central unit formed around a microprocessor of the 80x86 kind of "Intel" (registered trademark) and the reference 105, the input-output unit grouping together, among others, the modem 45, an organ display 110, a keyboard 115 and a mouse 117. The operation of this device is governed by a set of software 200.

 This software 200 is composed of different software blocks.

 A first block 201 is the block called the engine block.

It is this block that orchestrates all the operations that take place between the other blocks.

 A second block 202 is the configuration file block which is a total or partial copy of the parameter file to be modified. For example, it is a copy of memory 62 containing a stack of parameters. This file is obtained by a command sent to the relevant switching device via network 1. This command can either be a remote processing command, to this configuration file, for the parameters of the switching device, or a remote processing command for a modem attached to the switching device.

A third block 203 is a so-called compilation block which translates. in both directions, the configuration file into a working file 204 which constitutes a fourth block. This fourth block is obtained by a fifth block 205 which is a set of database management functions (library of functions for the C language) of type C
ISAM of the company of the United States of America "INFORMIX" (registered trademark) in California.

 The device is organized in such a way that it is offered to several kinds of users and operators. There are two kinds of operators - the supplier operator, - the customer operator.

Among the customer operators, there are - the customer user.

- the confirmed user and - the expert user.

 The operation of this device will now be described in detail, in the case of a switching member.

 In what follows, we will have to call on the syntax of the C language and we will mention the following types of variable - COUNT: integer signed on 2 bytes, - UCOUNT: unsigned integer on two bytes, - TEXT: character on one byte, - UTEXT: unsigned character on one byte, - LONG: integer on four bytes.

 The provider operator must provide a configured database. This work consists of starting from a multitude of parameters, around 30,000, as already mentioned, and assigning them to a tree structure.

1-) ORGANIZATION OF THE CONFIGURATION FILE
(for switching device).

 This configuration file is a binary file which reflects the parameter file contained in the memory 62 of the switching member. The memory representation of this file consists of a copy of the file in an array whose address is defined by a pointer p ~ file ~ bin, ie "UTEXT * p ~ file ~ bin". The length is saved in a variable size ~ file ~ bin of type UCOUNT, ie "UCOUNT size ~ file ~ bin".

The constructor of the switching device of the kind mentioned organizes the parameters of the device according to a hierarchy of classes and recurrences respectively. In each pair, (class Cww, recurrence Rxx), all the fields of the Pyy parameters have the same length. So a parameter can be written
CwwRxxPyyy where ww are two bytes of definition of the class number,
xx are two bytes of definition of the number of the
recurrence and
yyy are three bytes for setting the parameter number.

 In the configuration file, all these parameters are stacked and are identified by an offset.

2-) ORGANIZATION OF THE COMPILATION FILE
(for switching device).

 This compilation file is a text file. The memory representation of the compiler file is based on a table whose address is put in a variable "UTEXT * p file ~ offset" and whose length is saved in the variable "UCOUNT size ~ file ~ offset".

 This file is indexed in class / recurrence and gives the offset value of the first byte of the class / recurrence pair in the configuration file and also gives the length of the parameters.

Thus it is possible to calculate the offset in the binary file. For example, let parameter 2 of class 1 and recurrence 2: C01R02P002E05. E05, or in general EUV indicates the position in byte of a subfield. In no case may EUV be greater than the size in byte of the field, this subfield being part of parameter P002. By addressing the compilation file by COlR02 (0102) it returns the offset of the first byte and the length of the parameters of the class / recurrence set. Or, for example
0102 00003456 00000004 where 00003456 is the above offset and 00000004 the length of the parameters.

Thus it is possible to find the offset "OFFBIN" in the binary file by performing, according to the syntax of the C language, the operation
OFFBIN = 0x00003456 + 1 * 0x00000004 + 5 = 0x0oe03469 in general offset [C / R] + (Pl) * length + E.

 3 *) ORGANIZATION OF THE DATABASE.

 This database is set up by the supplier operator. Figure 4 partially shows a possible tree structure. To describe this tree structure, the terms branches and leaves will be mentioned as is the custom. The following indications are always given in the context of the example described. In this figure, different boxes are attached either to branches or to leaves.

Their meanings are as follows: the box KO represents the version and the reference of the switching device. From this box, two branches were identified, identified by boxes K1 and K3. Box K1 relates to an access key for the device of the invention for a user, so that the latter can in particular access the remote control functions of the switching device. The value of this parameter is shown in box K11 and therefore determines the read and write protection of certain parameters.

 The branch K3 relates to the configurable lines which are attached to the switching device. There are 42 lignO (box K300) to lign41 (box K301). Only the branches starting from box K30 are a little more detailed. Box K35 relates to the type of line, that is, this line can be of the X25 synchronous type, of the asynchronous type or of the SDLC (Synchronous Data Links Control) type.

 The branch that starts in box K36 relates to the parameters themselves. From this branch we derive a plurality of sub-branches, some of which are explained here: a sub-branch starting in box K37 relating to synchronous lines X25, another in box K38 relating to asynchronous lines and another in box K39 relating to SDLC lines. As regards the synchronous lines X25, a branch leads from box K37 to a box K40 which leads to a plurality of sheets K41, K42, ... The sheet K41 is the parameter defining the profile of the line, the sheet K42 the type of connection.

For asynchronous lines, two sub-branches K50 and
K51 are derived from the branch K38 and relate respectively to the parameter classes c112 and c113. Pluralities of leaves are linked to each of these branches
K52 and K53 on the one hand and K56 and K57 on the other which are to be compared with the sheets K41 and K42.

 4.) CREATION OF THE DATABASE.

 Once a tree structure has been defined, the corresponding database should be created.

 A database is made up of files forming files whose name is of type * .DAT to which are attached indexes which facilitate and accelerate the search for these files and which are files of name * .IDX to remain in the nomenclature of the aforementioned database manager. Among these files, there are the files relating to the levels and the files relating to the sheets. These sheets are structured as follows.

 4-1 Structure of the level sheets.

This structure is given in table I below using the conventions of the C language. All of these files will constitute the file NIVEAUX.DAT
TABLE I typedefstruct (
TEXT deleteflag
LONG code ~ level;
LONG code ~ levelpere;
LONG code ~ level ~ son ~ a;
LONG codeniveau ~ frerep;
LONG codeniveaufreres;
TEXT bool ~ level ~ file;
TEXT code ~ compiler;
TEXT bool ~ level ~ shift ~ automatic;
}LEVEL;
A chaining was carried out between the nodes of the tree structure so as to traverse this one as quickly as possible, for the various possible actions on the trees.

 A configuration level is uniquely identified in the database by its "code" (code ~ level in table I) symbolized by a LONG (4 bytes). Chaining therefore implies that the code of the father, the next brother, the previous brother and the eldest son is known, or respectively code ~ level ~ father, code levelfrere ~ s, codeniveau frereg; code ~ level ~ children ~ a.

Thus, referring to FIG. 4, and identifying the reference of the boxes with the level codes, one can write for the level of the box K38 code ~ level ~ father: K36 code ~ level ~ brother ~ s: K39 code ~ level ~ brother ~ p: K37 code ~ level ~ son ~ a: K50
At each level created, we update a code variable ~ new ~ level which contains the code for the next level that will be created. This variable is saved on the hard disk 51. During the initialization of the database, if there is no NIVEAUX.DAT file, the file is created and the file of the root level takes the code 1 (in the example would be KO). The first level created by the operator will therefore have the number 2 or box K1 if the operator starts with this box, or box K2 if it starts with this one.

The other codes given in table I are explained below under - bool ~ level ~ file: this boolean code indicates whether a file
parameters is associated with this level.

- code ~ compiler: this code indicates the type of device to which
refers to the specific file. Possible values
are
0: SWITCHING BODIES.

 1: MODEMS.

 2: MULTIPLEXERS.

this code therefore makes it possible to deduce the compilation technique from
use.

- bool automatic shift level: this boolean code indicates whether at
level is attached a specific file or if this level is
subject to filtering.

- delete flag: allows the management of the database,
especially to delete the records.

4-2 Structure of the parameter files;
This structure is given in Table II below.

All of these files will constitute the PARAMS.DAT file
TABLE II typedefstruct {
TEXT delete ~ flag
TEXT alignment [3];
LONG code ~ level ~ father;
TEXT visibility ~ param;
TEXT type ~ param;
TEXT bool ~ param ~ modi;
TEXT coding ~ param;
TEXT nb ~ bytes ~ coding ~ param;
TEXT number ~ param ~ file ~ reference;
TEXT name ~ param [LG ~ NAME ~ PARAM + 1];
TEXT ext ~ name ~ param [LG ~ EXT NAME + 1];
TEXT position ~ param [LG ~ POSITION ~ PARAM + 1];
TEXT description ~ paramCLG DESCRIPT PARAM + 11;
TEXT value ~ paramCLG VALUEPARAM + 1);
TEXT rules ~ input ~ param [LG ~ value ~ PARAM + 1];
TEXT fcts ~ configuration [NB ~ FUNCTIONS ~ CONFIG] (LGFUNCTION ~ PARAM + 1];
TEXT tests ~ integrity [NB ~ TESTS ~ INTEGRITE] (LGFUNCTION ~ PARAN + îJ;
}SETTING; - delete ~ flag: this is a byte reserved for database management.

- alignment [3]: framing bytes for the next field.

- code ~ level ~ father: code of the level where the parameter is defined.

- visibility ~ param: this byte defines the level of privilege
that the operator must have to gain access to this
setting. Either we are dealing with the client user, or
the confirmed user, or the expert user.

- type ~ param: we define the type of parameter, four types
are possible
- link type = O (reserved for an extension),
- param ~ common type = 1 (indicates that the parameter is
common with others),
- param type ~ profile = 2,
- param type ~ link ~ profile = 3,
these types relate to preset profiles.

- bool ~ parnm modi: this boolean value indicates if the value
of the parameter has changed since the reading of the file
configuration. During assembly, the compiler does not process
that the parameters changed.

- codagegaram: byte specifying the type of coding of the
parameter in the configuration file. Values
possible are
binary,
ascii
hexadecimal
quartet - nb bytes coding ~ param: size in bytes reserved in the
configuration file for the parameter.

number ~ param ~ file ~ reference: byte signifying the number of the
parameter in the reference profile. The byte is
significant if type ~ param = TYPE ~ PARAM ~ LINK ~ PROFILE.

- param name: ASCII string representing the name of the parameter.

- ext nomgaram: ASCII string representing an extension to
name of the parameter.

- positionparam: ASCII string specifying the position of the
parameter in the configuration file so the value
CwwRxxPyyy.

- descriptiongaram: ASCII string representing the
descriptive comment of the parameter.

- valeuyparam: ASCII string representing the value of
setting.

- param input rules: ASCII string representing the
constraints imposed by the operator on entering the
parameter value. It represents the limits of the values
the parameter, also specifying whether these values should be
entered using the keyboard or from a list in a drop-down menu.

According to an important characteristic of the invention, we define - fcts ~ configuration: ASCII string tables representing
configuration functions linked to the parameter. For
each parameter, the operator can define 8 functions of
configuration.

According to another important characteristic of the invention, we further define - tests-integrity: ASCII string tables representing the
integrity tests related to parameters. For each parameter,
the operator can define 4 integrity tests.

 5-) THE MOTOR BLOCK.

 I1 aims to manage the operator's actions which consist essentially of dialogues with the output input unit 105. It is therefore necessary to interpret the commands struck on the keyboard 115, activate the screen 110 in accordance. Provision should also be made to activate modem 55 for transfers between the configuration file and the parameter stacks contained in the remote equipment.

 5-1 Viewing levels and parameters.

Figure 5 shows the appearance of a screen. This screen is divided into two parts P2 and P2. On the part P1, various boxes KS1, KS2, KS3, KS4, KS5, KS6 are represented,
KS7, KS8, KS9, KS10 intended for exploring the tree structure. The boxes KS1 to KS3 are considered to be unused. The KS4 box is used to allow viewing of the levels. In the context of the example described, only the box KO of the tree structure shown in FIG. 4 will be registered. It is assumed that in boxes KS5, KS6, KS7 are written the levels K3, K30 and K36 and starting from there, the user wants to explore the rest of the tree structure. A descriptive comment is entered in box KS12. Using the mouse, he clicks on the KS8 box so that a drop-down menu appears on the KS20 box. This box does not always have the surface necessary to represent all the branches relating to the level concerned. It will therefore be possible to scroll in this box all the branches of this level (scrolling). In the case of figure 5, this box is sufficient to represent the levels depending on the level
K36. Or the levels K37, K38, K39: using the mouse, according to known techniques, by "clicking", it will be easy to select one to make it appear in the KS8 box.

Either, for example box K38 and from there, we can arrive at box K53. As K53 is a leaf in the tree structure, we are dealing with a parameter that we can modify. To do this, we use the P2 screen part which displays the parameter file. For this purpose, it includes boxes KS30, KS31,
KS32, KS33, KS34 and KS35. The KS30 box indicates the name of the parameter (name ~ param) and the KS31 box its extension, the box
KS32, its value (value ~ param), box KS33, a description of this parameter (description ~ param), box KS34, the limits between which the value of the parameter must be understood (rules entered by parameter) and box KS35 the type coding of this parameter (codinggaram).

 5-2 Parameter modifications.

 Associated with each parameter value are files associated with profile parameters which make it possible to make drop-down menus to propose choices for the value of the profile parameter. To each value of these parameters are also associated reference files which are binary files which make it possible to initialize the values of parameters linked to a profile. Therefore, the modification of the parameter values is carried out using these files.

 For this, we define an imagegar variable "of structure" PARAMETER "see table II. Then, by means of a function" memo ~ parametre (index) "we transfer into backup tables" memo-- "at index "index" the following fields of the variable "imagegar" memo ~ level []: "code ~ level ~ father", memo ~ name ~ param []: "extnomparam".

 We then use a "restoregarameter (index, flag ~ operation)" function to perform a search in the database of the parameter defined in the "memo-" backup tables with the index "index".

"flag ~ operation" indicates whether the record should be fully loaded or not. The parameter is searched according to the index "code ~ level ~ father", "name ~ param" and "ext ~ name ~ param".

 Finally a function "modifies Valeurgaram (vall, va12, flag ~ test, level ~ stack, rest ~ functions)" actually performs the modification. This function however checks that vall and val2, which represent respectively the current value and the value proposed for the modification, are different.

 "level ~ stack" indicates the current index of the "memo-" tables.

 If the current parameter is of type "TYPE ~ PARAM ~ PROFILE" the function is responsible for modifying profile parameters of the same name in the open parameter file.

 If the current parameter is of the type "TYPE ~ PARAM ~ PROFILE", the function must calculate the number of deltas or differences compared to a reference profile of the parameter. If "flag ~ test" = O the number of deltas does not change. Otherwise, the function compares the reference value of the parameter with the new value. If necessary, it modifies the registration of the profile parameter.

 The "modifygargar ()" function searches for the parameter in the current level. If the parameter does not exist in the current level, it searches the entire parameter file. To modify the registration, she re-calls herself. A variable "level ~ stack" limits the number of re-calls.

 6-) COPY / CUT / PASTE FUNCTIONS.

In fact, there are two groups of operations to be discerned a) the COPY / CUT / PASTE functions which are reserved
to supplier operators having to build the base of
which apply to copying, cutting and
collage of branches and their leaves from the base of
data, b) COPY / PASTE operations which are reserved
only to customer operators who only deal with
parameter values, so leaves.

These functions use - MOTOR.C - G ~ LEVEL.C - B ~ LEVEL.C - C ~ SYNTAX.C
To perform these functions, different variables are required.

LEVEL ~ IN ~ COURSE: which is the level we are working on.

DIRECTORY DESTINCLGNOM DIRECTORY + 11: this variable
represents the name of the destination directory used by
the three aforementioned functions.

* tab ~ pointer ~ files ~ destination [NB ~ MAX ~ FILES ~ REP + 1]: is a
table intended to receive the list of the basic files of
remote directory data. It is essential for the
PASTE function and it is used by the function
"tests ~ paste ~ base ()" from B ~ NIVEAU.C.

 6-1 COPY function.

 The prior operation consists in calling on the following functions.

- destroy directory file ():
this function destroys all files in the remote directory
who is the recipient of the database files
local (only for the selected tree structure).

- g ~ copierdase ():
This function launches two functions: "copy base ()" from
B LEVEL.C which really launches the COPY operation of the database
and "g selectionniveau ()" from G ~ NIVEAU.C which allows you to
reposition on the initial level, selected for the
TO COPY.

 6-2 CUT function.

The CUT operation is reduced to a COPY operation of the tree structure and then to its destruction. We actually execute the function "gbestruction ~ tree levels () of
G ~ NIVEAUX.C which in turn launches a function "destroy tree levels ()" of B NIVEAU.C.

 6-3 PASTE function.

 The PASTE operation implies that the following functions are launched - lists ~ files ~ directory () of the file C ~ SYNTAX.C.

This function returns the number of files found in the
remote directory since if this number is zero no PASTE
cannot be performed.

- g ~ tests paste base () of the file G ~ NIVEAU.C.

This function calls the "tests ~ paste ~ base ()" function of
B ~ LEVEL.C which tests if it is possible to perform
the PASTE operation and displays the error or error messages
confirmation.

- g ~ paste base () of file G ~ NIVEAU.C.

This function calls the "paste ~ base ()" function of
B ~ LEVEL.C which performs the PASTE proper and displays
reporting messages if applicable.

 7t) APPLICATIONS FOR MODEMS AND MULTIPLEXERS.

 7-1 Modems.

For a modem, a configuration file is a series of HAYES commands which are accompanied by an AT preamble. There are three possible command syntaxes
AT - ATPxxx = yyy with xxx between O and 999 and yyy between O
and 255.

- ATSxxx = yyy with xxx between O and 999 and yyy between O
and 255.

These ATP and ATS commands relate to the loading into the modems of values for different programming registers that the affected modems contain.

- ATTxxx = number ~ of ~ telepone with xxx between O and 999
and phone number which is an ASCII string of 30
maximum characters.

 In the configuration file, the AT commands have a very specific order. ATP commands come first, ATS commands second and finally ATT commands. The representation in memory of the commands of the configuration file is done by tables for ATP and ATS commands and by linked list for ATT commands.

7-2 Multiplexers;
This kind of device is described in the article by
N. Ghesquiere and P. de La Bourdonnaye entitled "Semanet 128 Terminal Adapter for Digital Networks" published in the English edition of the journal Commutation et
Transmission No. 2 from 1992.

 The configuration file is also a series of AT commands. The number of command syntaxes being very large, there is no test of the syntax of a command in the input file. This is reproduced in the output file.

Claims (9)

1) Device for managing parameters of a large system formed of different elements provided with circuits presenting adjustment parameters to be managed, device comprising: a main management organ formed from a processor to which are attached - a memory organ mass and input-output elements, - a transmission element for receiving the information describing the parameters to be adjusted and for transmitting the information describing the parameters to be modified, all by means of the system, characterized in that it includes - import means cooperating with the transmission device, to receive, in a configuration file created in the mass memory device, parameters of a circuit to be adjusted, - means for transcribing the files configuration in database files, - means for modifying the databases by means of input-output devices, - means for transcribe the modified database files into modified configuration files - and repatriation means cooperating with the transmission device, to (download) the configuration files to the circuit to be adjusted. 2) Device for adjusting parameters according to claim 1, characterized in that there are provided integrity test means. 3) Device for adjusting parameters according to claim 1 or 2, characterized in that the means for modifying the databases imply means of modification of implicit parameters to modify the parameters in accordance with the modification of the current parameter. 4) Device for adjusting parameters according to one of claims 1 to 3, characterized in that there are provided compilation means formed of compilation files each assigned to a type of said circuits to be adjusted. 5) Device for adjusting parameters according to one of claims 1 to 4, characterized in that the database file is organized in trees. 6) Device for adjusting parameters according to claim 5, characterized in that means are provided for copying subtrees. 7) Device for adjusting parameters according to one of claims 1 to 6, characterized in that the parameters are accessible for user classes (customer, confirmed, expert). 8) Device for adjusting parameters according to one of claims 1 to 7, characterized in that the parameters are defined by different fields. 9) Device for adjusting parameters according to one of claims 1 to 8, characterized in that the parameters include a code which allows them to be quickly located in the configuration file.