WO2000054153A2

WO2000054153A2 - Method and device for processing orders

Info

Publication number: WO2000054153A2
Application number: PCT/DE2000/000760
Authority: WO
Inventors: Roland Riedlinger; Ingrid KRÄMER
Original assignee: Siemens Aktiengesellschaft
Priority date: 1999-03-11
Filing date: 2000-03-10
Publication date: 2000-09-14
Also published as: WO2000054153A3; DE19910863A1

Abstract

Conventional distributed processor systems comprise a multitude of processor units in which a standard protocol for safety-relevant processes has to implemented separately by each interface partner. This can lead to errors in the signal chain. The aim of the invention is thus to improve the reliability of such systems and to offer the advantages of a fixed protocol frame, system-wide definition of behaviour in case of a job protocol violation and robust software, i.e. easy maintenance and high test efficiency. According to the invention the processor units (8-24) comprise first and second means for receiving and processing messages. The first means are part of the application program and the second means are application-independent and equally present in all processor units. The method provided for by the invention consists of the processing of a received message in an application-independent manner which is the same for all processor units. The invention is used in telecommunications, notably switching centres and in particular ATM systems.

Description

description

Device and method for processing orders

The invention relates to an apparatus and a drive Ver ^¬ for processing application and in particular egg ^¬ ne plurality of processor units with each other to exchange messages.

Distributed processor systems for real-time critical applications are used in telecommunications. These processor systems are based on a software architecture that must be multi-taskable, i.e. enables the processors to meet the incentives and requirements acting on them simultaneously and in real time.

Such systems receive incentives or requests from the outside, for example, via interface cards. These incentives are then distributed within the system for further processing. This pure forwarding of information accounts for about 30 ° of the internal process communication volume.

The remaining portion of approx. 70 ° _o is used to support safety-related processes. This includes, for example, standardized acknowledgment messages, repetitions of messages and surveillance messages, which serve to increase communication security. This enables software and hardware errors, such as the failure of individual or multiple processor platforms, to be quickly identified. This optimizes the system response time and increases the performance and robustness of a system.

In conventional systems, the receiving, sending and processing of acknowledgment messages, message repetitions, monitoring messages etc. must be supported by each communication partner in its own application. This sets in _S ahead that must be implemented independently of each interface partner tandardprotokoll. May be because the ver in the system ^¬ shared processors on various and varied platforms, different applications can be submitted and m different client-server Constellation ones can be set up, a feh ^¬ lerfreie reporting chain let not achieve under certain circumstances, for an error-free message chain requires the same behavior of the individual partners.

The Technische Rundschau 1998, Issue 9, pages 34-38 by RYTZ, B .: "Middleware: the slash on the client / server" deals with middleware. Middleware is defined as the slash "client / server". Middleware is also described as universal communication software above the transport level and as usable wherever spatially distributed IT systems communicate with each other.

DE 195 02 728 AI discloses a telecommunications device, which can be a digital switching device. Software is provided to control functional sequences. The switching device contains a central control unit which has two microprocessor units working independently of one another. To handle the control processes in these microprocessor units, software is provided that is hierarchically divided into layers, of which the bottom layer contains program units that are used to implement operating system functions and are the same for all software configurations. The device described is intended to shorten the production time.

The invention has for its object to provide a device and a method for processing orders with greater reliability. This object is achieved according to the invention by the subject matter of claims 1 and 17.

The anwendungsunabhangige and taking place for all processor units in the same manner processing of a message has ^¬ nearest the advantage that the user can be offered an implementation of standard run in a fixed protocol frame. This makes it possible to reduce the technical security effort when implementing an application. When using conventional devices and methods, this effort generally exceeds the effort for the actual implementation of user-related actions.

In addition, the application-independent processing of messages, which is carried out in the same way in all processor units, ensures system-wide behavior in the event of a protocol violation, e.g. if there are no receipts or program reports and if the requirements are canceled. This has the further advantage that the system response time is further optimized.

In addition, according to the invention, an apparatus and a method are advantageously created which enable efficient maintenance, since safety-related processes are no longer carried out by the individual application programs. This enables maintenance at a central location without the individual applications having to be implemented again.

Finally, compared to conventional systems, a high level of robustness of the safety-related processes in the distributed processor system can be achieved in a shorter time, since according to the invention, application-independent routines are used for these processes, which routines are used in all processor units Similarly, are present and therefore-users repeatedly tested and corrected if necessary by the individual Be ^¬.

Preferred embodiments of the invention are defined in the subclaims.

The invention is explained in more detail below on the basis of preferred ^embodiments with the aid of the figures, in which:

Figure 1 illustrates a distributed processor system to which the invention applies;

Figure 2 shows a tent log of the processing of an order; and

Figure 3 is a flow diagram illustrating a process structure.

1 shows an advantageous embodiment of a distributed processor system. A number n of processor platforms 2, 4, 6 each comprises a plurality of processor units 8-24, which can execute a number m of processes on each platform. The processor units are advantageously designed in a client-server configuration.

The platforms preferably have the same or similar configuration. But they can also be of a fundamentally different shape. For example, the number of processor units per platform can vary widely. The processors of different platforms and different processor units of one platform can also be identical in construction, but can also be of different construction.

The processor units are preferably provided by the operating system through virtual processors. Only one process runs on a virtual processor. This technique, a physical processor m divide several vir ^¬ tual processors found in multitaskmg-fahi- gen operating system application. Therefore, preferably several or all processes run on a multitasking principle in real time. Interface cards are usually built with a processor that can also be duplicated due to security measures (redundancy).

In a preferred exemplary embodiment, the distributed processor system shown in FIG. 1 is used for processing orders in the field of telecommunications. The distributed processor system of FIG. 1 is preferably part of an exchange. A particularly advantageous embodiment of such a switching center is a system that supports the ATM standard.

In general, the distributed processor system shown in FIG. 1 can also be used for other forms of device control. The processes are advantageously implemented as software.

As shown in FIG. 1, the server S of the processor unit 8 receives a trigger signal. This signal can be an incentive or an external request, but can also represent the output signal of another platform. In the example shown in FIG. 1, the information content of this received incentive is forwarded via the client of the processor unit 8 to the server of the processor unit 10 and in the same way to the processor units 14 and 16 of the platform 4. This creates a message chain.

FIG. 2 shows an example of a time log of an order processing in one of the servers shown in FIG. 1. As can be seen from the figure, the server has genetic routines 30, 34, 36, 38, 42 and specific routines 32, 40. Specific routines are part of the application. Conversion programs and genetic routines are those that are application-independent and available in the same way for all processor units.

Receipt of the server from the client or by a Triggersig ^¬ Nalles a job or a job, an overall joint and several routine 30 executed for acknowledgment of this order in the server. The server then sends an acknowledgment or acknowledgment back to the client. Regardless of this generic routine, an application-specific routine 32 processes the job.

This specific processing may be due to the forwarding of the order to another client. In this case, communication takes place between a client and a server. When an order is forwarded, the original server (incoming order) takes the position of the client. From this position, the job is sent to another server. A communication partner always takes both positions (server / client) when forwarding an order.

If an acknowledgment comes back in response to the forwarded job, a generic routine 34 for acknowledgment monitoring is started. By default, this routine determines whether the acknowledgment meets the requirements of the protocol in terms of its information content and in terms of its reception time. If this is the case, the generic routine 34 is ended.

Another circumstance can occur when a report or a progress report is sent back from a monitored interface. The server then takes the position of the client to forward orders and the (target) server sends a report or a process report to the

Client back. In this case, the client executes a generic interface monitoring routine 36. These The routine first confirms the received report and then checks whether the information content and the time frame of the program report require a response. If this is not the case, the generic routine 36 for interface monitoring is ended.

Hits a result the client one, the client leads initially a generic routine 38 resets this ^¬ He gebnisnachricht out. Such a result message preferably consists of the notification that the job has been carried out correctly by the recipient. In the event of an error, the result message may contain an error message. After the generic routine 38 has acknowledged the result message, the result is passed on to the previous communication partner, ie from the server to

Client. The result message, previously recorded by the client, is forwarded internally to the server interface. A specific routine 40 is executed which processes the result message in the sense of the application program. Preferably, the specific routine will forward the result message to the precursor client.

When the result message is sent, a generic routine 42 for acknowledgment monitoring, which preferably corresponds to routine 34, is started. Finally, the server receives an acknowledgment from the client that received the result message and then ends the acknowledgment monitoring.

The generic routines 30, 34, 36, 38, 42 can be regarded as part of a generic job handler which makes it easier for the application program to process standard processes by processing incentives or events and specifying appropriate standard processes. As can be seen from the example shown in FIG. 2, the generic job handler automatically acknowledges the communication partner after receiving a message. Preferably, the generic job handler further Generi ^¬ specific routines will contain, for example, repeat the transmission of a message if an acknowledgment fails to appear. Such a routine is preferably started by the generic routines 34, 42 for acknowledgment monitoring.

The generic job handler preferably also contains a routine for abort handling, which can be started by the generic routines 34, 42 for acknowledgment monitoring if an acknowledgment is missing and a repeated transmission of the original message is not sensible or is not desired by the application program.

As the figure 2 it can be seen, the server leads so ^¬ from well generic and specific routines, wherein the time expiration of the routines can engage. In the example shown in FIG. 2, a routine is first ended before another routine is executed. However, several routines can also be executed simultaneously, ie in multitasking mode, in which case parts of different routines interlock.

For this purpose, the generic job handler is kept user-neutral, while user-specific data are declared or defined in a so-called instantiation. In this context, instantiation is understood to mean the generation of a computer-internal data structure for representing an object on the basis of a generic description. The properties of the generic description are generally transferred to the concrete object, the instance.

The interface between the user and the generic job handler is a so-called DO list, which contains general instructions. With their help, the user is placed in the position to use standard processes generic job handlers are specified to specifically implement their application. An example of this is explained with reference to FIG. 3.

After starting the application program under reference number 50 the message are received, from a specific routine 52 ^¬ gen. Then create a specific routine 54 a DO list that generality DEFINITELY instructions contains, as the acknowledgment, the repetition of messages or Uber- monitoring of server interfaces through program reports. The specific routine 56 executes the user-neutral DO list. In the generic routine 58, a comparison is made as to whether the instructions in the DO list could be executed successfully. Only the successfully executed instructions (DONE LIST) are deleted from the DO list. A generic routine 60 then queries a READY register. In the event that this register exists, which is checked under reference numeral 62, the job according to the READY register is carried out by a specific routine 64. A generic routine 66 then compares the DO list with the DONE list and adjusts the DONE list accordingly.

The routines shown in FIGS. 2 and 3 are preferably pure software solutions.

Claims

claims

1. A device for processing of orders, comprising a plurality of processor units (8-24) which are to exchange messages and in each case at least one appli ^¬ exports education program, which serves the processing of orders,

wherein the at least one application program of each processor unit is suitable for processing received messages, and

the processor units are set up for application-independent processing of received messages in a manner that is the same for all processor units for the automatic processing of standard security-related processes.

2. The device of claim 1, wherein the device is an exchange.

3. The apparatus of claim 2, wherein the switch is an ATM switch.

4. Device according to one of claims 1 to 3, wherein the orders are processed in real time by the processor units in multitas kmg mode.

5. Device according to one of claims 1 to 4, wherein the processor units have a client-server configuration.

6. Device according to one of claims 1 to 5, wherein the orders serve a device control.

7. Device according to one of claims 1 to 6, wherein the security-technical standard processes include the sending of receipts.

8. Device according to one of claims 1 to 7, wherein the security-technical standard processes include receiving and sending program reports for monitoring an interface.

9. Device according to one of claims 1 to 8, wherein the security-related processes include the forwarding of a message.

10. Device according to one of claims 1 to 9, wherein the safety-related processes include error handling.

11. The apparatus of claim 10, wherein the error handling causes an early termination of a job in the event of an error.

12. The apparatus of claim 10 or 11, wherein the error handling repeats the sending of a message in the event of an error.

13. Device according to one of claims 1 to 12, wherein user-specific data are declared in an instantiation by means of a DO list which contains general instructions.

14. The device according to one of claims 1 to 13, wherein the application-independent processing and the processing by the application program take place in a time-interlocking manner.

15. Device according to one of claims 1 to 14, wherein the processor units have implemented software for carrying out the application-independent processing.

16. The device according to one of claims 1 to 15, wherein the processor units are implemented as virtual processors.

17. A method for processing orders in a multiplicity of processor units (8-24) which exchange messages with one another and in each case execute at least one application program which serves to process the orders, with the following steps:

Receiving (52) a message in a processor unit,

application-independent processing (54) of the message in the same way for all processor units for the automatic processing of safety-related standard processes, and

Processing (56, 64) of the message by the application program.

18. The method according to claim 17, wherein the processor units are part of a switching center.

19. The method of claim 18, wherein the switch is an ATM switch.

20. The method according to any one of claims 17 to 19, wherein the orders are processed in real time by the processor units in multitasking mode.

21. The method according to any one of claims 17 to 20, wherein the processor units sen a client-server configuration aufwei ^¬.

22. The method according to any one of claims 17 to 21, wherein the orders serve a device control.

23. The method according to any one of claims 17 to 22, wherein the security-related standard processes include sending acknowledgments.

24. The method according to any one of claims 17 to 23, wherein the standard security procedures include receiving and sending program reports for monitoring an interface.

25. The method according to any one of claims 17 to 24, wherein the security-related standard processes include the forwarding of a message.

26. The method according to any one of claims 17 to 24, wherein the safety-related standard processes include error handling.

27. The method of claim 26, wherein the error handling includes early cancellation of a job in the event of an error.

28. The method of claim 26 or 27, wherein the error handling is the repeated sending of a message to a

Error included.

29. The method according to any one of claims 17 to 28, wherein in the step of processing the message by the application program user-specific data in an instantiation ent holds ^¬ by a DO list that general statements be declared.

30. The method according to any one of claims 17 to 29, wherein the application-independent processing and the processing by the application program are carried out in time.

31. The method according to any one of claims 17 to 30, wherein the messages are processed by software.

32. The method according to any one of claims 17 to 30, wherein the message is processed by virtual processors.