EP0492252B1 - Communication system comprising exchange connection groups, a switching network, a central signalling channel and a multiprocessor system for centralized control - Google Patents

Abstract

Communication systems often need to be extended during operation through the addition of extra subscribers. Extra subscriber data are added on a disk store. Care must be taken to ensure that previously installed patches with their physical addresses are not modified. <IMAGE>

Description

The invention relates to a device according to the preamble of patent claim 1.

Complex communication systems are mostly implemented as multiprocessor systems. These have advantages over monoprocessor systems, such as a drastic increase in processing speed. This is achieved by processing several tasks in parallel, each of which represents subtasks of a task to be processed; Each processor processes a subtask and the subtotals are put together to form an overall result. In addition to the high processing speed, another requirement placed on modern communication systems is to ensure that the system is available to all participants at all times, which is achieved by largely duplicating central parts of the system. International standardization bodies for communication systems / communication networks - for example CCITT - make demands for high availability of the system over its entire lifespan, for example in the form that a communication system may fail for a maximum of two hours over a period of 20 years. In order to meet these requirements, the system's internal processes must be controlled and monitored by a large number of processes and procedures. However, this increases the complexity of the procedures and processes taking place in a communication system drastically. In general, the more complex and complex a system is, the higher the probability of errors. Therefore, the errors that occur during operation must be analyzed and correction data must then be introduced directly into the system in order to reduce the likelihood of errors in the system and thus increase the availability of the system. In general, mistakes when creating procedures are inevitable. Although syntax errors in the course of the creation by special procedures, such. B. compiler procedures, can be eliminated, but logical coding errors can not be determined via such a syntax check; they therefore have an effect during ongoing operation and occur particularly where there is a complex interplay of procedures and processes. However, the complexity of such a system only makes the occurrence of a logical coding error possible after a long operating time and makes it difficult to rectify such an error immediately.

Although conventional monoprocessor systems allow the time-consuming and labor-intensive work to correct, compile, and then re-encode and re-encode the procedure sequences, and to reintroduce them into the system, such a procedure is practical with the multiprocessor-based communication systems used today no longer possible, since the introduction of even the smallest corrections would mean re-editing, compiling and binding of all procedures of the entire communication system. Such a process would generally take several days and would block data centers for a long time.

The need to develop methods that allow minor error corrections to be introduced quickly and quickly into the software of a communication system has led to the development of procedures for the rapid correction of logical ones Coding errors, hereinafter referred to as patches. Patches can be used to make small software corrections at short notice. The changes are directly supplied to the code sequences to be corrected in the respective procedures by instructions via an operating terminal. In the case of simpler logical coding errors, the incorrect code is overwritten. However, if additional code has to be added to the program flow, the patch is connected to a so-called 'backpack'. This contains the additional program code that is necessary to correct the logical error and is stored in a memory area specially provided for this purpose. The correction of the now changed program code becomes noticeable in the later sequence in that the procedure branches to the inserted 'backpack' at the corresponding change point, and after processing it returns to the original program code. This process is controlled via a so-called patch management. In this table the addresses of the 'backpacks' assigned to the patches are stored.

The creation of the procedures of a communication system implies several, complex development steps, because on the one hand, the procedure immediately after the coding process still contains errors, which are only eliminated after further development steps and, on the other hand, further performance features are added, which usually means that further procedures are integrated in the software of the communication system.

For organizational reasons, each version step is assigned a version number. However, a patch only brings temporary error corrections into the system that do not create new versions. If new procedure components are created and integrated into the system in the course of the use of new performance features, to which new version numbers are then assigned, this opportunity is used to completely incorporate the - temporarily - introduced patches into the procedures. In the one procedures with a new version number are no longer included in the "former" patches.

• modulübergreifend auftreten,
• prozessorübergreifend auftreten,
• nur dann auftreten, wenn eine bestimmte Netzumgebung vorhanden ist, oder
• nur in Verbindung mit einer entsprechenden Firmware auftreten.

With this procedure for fast error correction (patch procedure) simple logical coding errors can be corrected at short notice and incorporated into the procedures of the communication system. Among simpler logical coding errors are e.g. B. to understand such errors that occur in a module to be processed by a single processor. Due to the development of multiprocessor systems, there are constellations that do not occur in a monoprocessor architecture. Logical coding errors are so complex due to the interaction of several procedures and processes that an immediate correction of incorrect code in the respective procedures is no longer easily possible. In addition to the errors known from the previous "monoprocessor world", such error types have also been added

• occur across modules,
• occur across processors,
• only occur if a certain network environment is available, or
• only occur in connection with the corresponding firmware.

Such complex logical coding errors can no longer be corrected with the described patch method and introduced into the system, since the error corrections - e.g. B. in the case of cross-module logical coding errors - must be introduced in one change step.

As already mentioned, the complexity of a system is directly correlated with its probability of error - and with it, its availability. In practice, this means that the more complex the system, the more patches - i.e. fast error corrections - in its modules, Procedures and tables are located. However, these patches access further procedures in the further course of the development process of the procedures of a communication system - in this case until the next version number is issued.

Fixed physical addresses are assigned to the patches in the working memory. If additional data are now to be inserted into the tables of the communication system in the course of a development process - in particular if additional participants are connected to the communication system - this is inherently associated with a shift in these physical addresses. However, this is avoided by analyzing the patches in question in a series of laborious individual steps and - temporarily - removing them in order to introduce the corresponding data. In particular, the removal of patches that have already been applied creates enormous problems in practice, since previously corrected errors can now appear again under certain circumstances. Since - as mentioned - patches already introduced access further procedures in the further course of the development process of the communication system, there is a not negligible probability of a total crash or a drastic limitation of the availability of the entire communication system.

The invention has for its object to provide a method to expand the communication system during operation by additional subscriber data with sufficient practicality, without limiting the availability.

Starting from the preamble of claim 1, this object is achieved according to the invention by its characterizing features.

It is essential for the invention to expand tables by additional participants, without any particular restriction of the switching traffic. The problem of temporarily removing patches that still exist in the tables is solved by adding additional subscriber data to an external storage medium. After the insertion process has been completed, the new tables are then loaded into the corresponding areas of the working memory step by step. This avoids a significant limitation in the availability of the entire communication system.

In the following the invention will be explained with reference to an exemplary embodiment shown in the figures.

• ein der Durchschaltung von Verbindungen dienendes Koppelfeld SN
• dem Anschluß von Teilnehmergeräten dienende Anschlußbaugruppen LTG₁...LTG_n mit Prozessoren P $\genfrac{}{}{0ex}{}{\text{L}}{\text{1}}$
  
  ...P $\genfrac{}{}{0ex}{}{\text{L}}{\text{N}}$
  
  und diesen zugeordneten lokalen Speichersystemen LMY
• eine der Steuerung eines zentralen Zeichenkanals CCNC dienende Anschlußbaugruppe mit Prozessoren P $\genfrac{}{}{0ex}{}{\text{N}}{\text{1}}$
  
  ...P $\genfrac{}{}{0ex}{}{\text{N}}{\text{n}}$
  
  und diesen zugeordneten lokalen Speichersystemen LMY
• einen Koordinationsprozessor CP, bestehend aus
  • -- einem für alle Einheiten des Koordinationsprozessors CP gemeinsamen Speichersystem CMY
  • -- einem für alle Einheiten des Koordinationsprozessors CP gemeinsamen zentralen Bussystem B:CMY
  • -- mehreren Prozessoren P $\genfrac{}{}{0ex}{}{\text{C}}{}$$\genfrac{}{}{0ex}{}{}{\text{1}}$
    
    ...P $\genfrac{}{}{0ex}{}{\text{C}}{\text{n}}$
    
    mit diesen Zugeordneten lokalen Speichersystemen LMY
• sowie weitere Anschlußbaugruppen IOP₁...IOP_n , die an den zentralen Systembus B:CMY des Koordinationsprozessors CP angeschlossen und über die externe Speichersysteme SP, externe Ein-/Ausgabegeräte PC sowie ein externes Rechenzentrum RZ anschaltbar sind.

1 shows a modularly structured communication system. This is shaped by

• a switching network SN serving for switching connections
• the connection of subscriber devices serving connection modules LTG₁ ... LTG _n with processors P $\genfrac{}{}{0ex}{}{\text{L}}{}$$\genfrac{}{}{0ex}{}{}{\text{1}}$
  
  ... P $\genfrac{}{}{0ex}{}{\text{L}}{\text{N}}$
  
  and LMY associated with these local storage systems
• a connection module with processors P used to control a central character channel CCNC $\genfrac{}{}{0ex}{}{\text{N}}{}$$\genfrac{}{}{0ex}{}{}{\text{1}}$
  
  ... P $\genfrac{}{}{0ex}{}{\text{N}}{\text{n}}$
  
  and LMY associated with these local storage systems
• a coordination processor CP consisting of
  • - A memory system CMY common to all units of the coordination processor CP
  • - A central bus system B: CMY common to all units of the coordination processor CP
  • - Several processors P $\genfrac{}{}{0ex}{}{\text{C.}}{\text{1}}$
    
    ... P $\genfrac{}{}{0ex}{}{\text{C.}}{\text{n}}$
    
    with these associated local storage systems LMY
• and further connection modules IOP 1 ... IOP _n , which are connected to the central system bus B: CMY of the coordination processor CP and can be connected via the external storage systems SP, external input / output devices PC and an external data center RZ.

In the exemplary embodiment, the external storage medium is designed in the form of a disk storage SP. This has access to the coordination processor CP via one of the connection modules IOP. All read / write processes between the working memories LMY, CMY of the coordination processor CP and the disk memory SP take place via this interface. The system software and special subscriber data running in the working memories LMY of the communication system are generally stored on the disk memory SP; the latter are organisationally combined in files, hereinafter referred to as data libraries, and consist of several library elements, which in turn contain several tables, which are implemented in the form of software modules. As already mentioned at the beginning, patches are introduced into the software during the development process of the procedures of a communication system. In the specific case of data tables, this means that patches are stored in any order between the subscriber data contained in the tables. These patches - like the other subscriber data, by the way - are stored under fixed physical addresses that are accessed by switching procedures and processes.

Each module is also assigned a so-called patch and module management. All data relating to a module, such as its logical start address and its length, are stored in the module management. Based on the knowledge of the starting address of a module and its length, procedures can be used to determine the logical addresses of the individual subcomponents of the module - namely the stored subscriber data and any patches that may be present. The patch management contains all data relating to a patch, such as the addresses of the patch within the module in question, its start address, all changes made in this module and the status of the patch being introduced. This means that the patch management assigned to a module can be traced at any time as to which data at which address was changed during the development process.

Furthermore, the code of the procedures of the communication system is organisationally summarized in libraries, the so-called "TASKLIBs". Here too, patches with possibly attached "backpacks" are inserted in any order during the development process of the software. For this reason, patch administrations and - since the procedures are implemented in software modules - module administrations are assigned to the tables containing the code. The code stored in the 'TASKLIB' accesses the data in the data library when it runs in the working memory. It must be ensured under all circumstances that the data stored in the data library is always stored at the same address so that the TASKLIB procedures can find the data relevant to them at the correct address at all times when accessing the data library. As a rule, this is also ensured.

Now, new participants are often added to a communication system. In practice, this means that data libraries containing the subscriber data must be expanded in this case; however, this gives the data patches new addresses that must be communicated to the access procedures stored in the 'TASKLIB'.

Before the data libraries are expanded to include further subscriber data, they are first copied to auxiliary libraries. The actual expansion processes are carried out in these. This has the particular advantage that the switching procedures can still access the old data libraries containing subscriber data and consequently the switching traffic is not interrupted.

In a first step, the previously inserted patches are removed from the corresponding modules using special procedures; the original state of the data is therefore restored. Because every patch, i.e. every change of participant data in the patch management assigned to the module this process can be carried out without particular difficulty. During this process, the switching procedures continue to use the tables in the main library, which eliminates the risk that the corresponding malfunctions will occur again when the patch is removed - which is basically equivalent to inserting old 'logical coding errors'.

In a second step, an expansion procedure ensures that data modules containing the subscriber data are expanded by additional memory area; the new participant data can be entered here later. A so-called shift procedure combines the data modules expanded in this way to form a new data library. It also assigns the new start addresses of the data modules to the old start addresses. Furthermore, the addresses must now be entered in the module management and the patch management. As a result of the binding process, the addresses under which the patches were previously located have also changed. Although the patches were removed from the data modules before the expansion, they are still contained in the patch administrations assigned to the data modules; Their status register only shows the status 'INACTIVE', which means that they are not considered to exist for the data modules and any procedures of the 'TASKLIB' that access them. In a third step, a further procedure now inserts the previously removed patches. At the same time, the associated new patch addresses are changed accordingly in the patch management of the data modules. This automatically updates the jump addresses to these patches in the code of the TASKLIB procedures. This ensures that, despite the physical addresses being shifted due to the expansion of the data modules, the TASKLIB procedures do not access patches of the data modules incorrectly.

In a final step, the libraries expanded in this way can now be loaded step by step into the main memory of the communication system.
A communication system designed in this way ensures that the general availability of the system is maintained for all participants.

The procedure is demonstrated in detail in the exemplary embodiment in FIGS. 2 to 5.
2 shows the TASKLIB, the data library and the associated patch and module administrations. For a more detailed explanation, a patch is inserted in module 3 of the data library. This patch is addressed by a patch from TASKLIB. In FIG 3, the patch in module 3 of the data library is removed.
FIG 4 demonstrates how the individual modules are expanded by additional storage space. This additional storage space is quasi 'attached' to the modules and later described with the corresponding subscriber data. The 'new' modules are then linked by a shift procedure to an updated data library, the 'new' module start addresses being communicated to the module administrations. As can be seen from FIG. 3, the address at which the patch was originally inserted has been shifted.
5 the patch is inserted again. By inserting the patch, the patch address is updated in the patch management. The updated patch address is also communicated to the patch management of TASKLIB and, as a consequence, the addressing code of the patch of TASKLIB, which addresses the patch of the data library, is changed accordingly.

Claims (1)

1. Method for controlling subscriber data in a communications system having

   - line trunk groups (LTG₁...LTG_N) via which subscribers are connected to the communications system,

   - a multiprocessor system (CP) which is used for central system control,

   - an external storage medium (SP) on which procedures and data, in particular subscriber data relating to the communications system, are combined in files comprising a plurality of modules, and

   - the respective modules for patch procedures for correction of software errors in resident module controllers and patch controllers assigned to procedures/data

   characterized in that new subscriber data are inserted into the files in such a manner that, after the files have been copied into auxiliary files, patches which have been inserted into procedures/data of the communications system are cancelled again by means of first procedures in accordance with the patch data stored in the patch controller, the modules which have been freed of patches are expanded by an additional memory space by means of a second procedure, and a shift procedure connects the modules which have been expanded in such a manner together to form an updated file and updates the initial addresses of the modules stored in the module and patch controllers assigned to the modules, the patches which were initially removed are inserted, via a fourth procedure according to the patch data stored in the patch controller, at new addresses, which are shifted by means of the attachment process, of the patches which were previously inserted, updating of the patch addresses which are stored in the patch controller being carried out by means of system-internal patch procedures, and the new subscriber data being written into the additional memory space via a fifth procedure and all the files being loaded successively into the main memory of the communications system.

Images