METHOD AND SYSTEM FOR MINIMIZING EFFECT OF REPLACING PROGRAMMING LANGUAGES IN TELEPHONY SYSTEMS

Abstract: A separate executing processor (107, 108, 114, 120, 121) is provided for a different programming language in each CP (100A, 100B) in a multi-CP digital switching system. As such, each CP (100A, 100B) in a multi-CP system can utilize a common program and data store (110-113, and 116-119) and scheduling unit (105, 200), which support two or more executing processors (107, 108, 114, 120, 121). Each executing processor (107, 108, 114, 120, 121) can execute a different application using a different programming language. Consequently, the CPs (100A, 100B) can execute applications using older programming languages, in addition to executing the same or different applications with new programming languages. This approach minimizes the impact of replacing the older programming languages with the newer languages.

Description: METHOD AND SYSTEM FOR MINIMIZING EFFECT Of REPLACING PROGRAMMING LANGUAGES IN TELEPHONY SYSTEMS BACKGROUND OF THE INVENTION Technical Field of the Invention The present invention relates in general to the telephony field and, in particular, to a method and system for minimizing the effect of replacing central processor programming languages in telephony systems. Description of Related Art There are numerous new design requirements being imposed on manufacturers of digital switching systems. For example, there are many new programming languages being required for use in digital switching system central processor software applications, in addition to very high capacity switch requirements. These new programming language requirements are being imposed on the manufacturers by both the telecommunication system operators that purchase the switching systems and the manufacturers themselves. As such, there are numerous and different new programming language requirements being imposed on digital switching system designs for different software applications, different customers, and also different business entities within the manufacturers ' own organizations. The primary reasons for these new programming language design requirements are the stringent time-to-market development and manufacturing constraints being imposed, the ability to purchase source code for certain software applications, and the fact that the existing switching system central processor programming languages are simply out-of-date. For example, the well-known PLEX programming language has long been in use for central processor software applications in the present generation of digital switching systems, such as in the AXE Digital Switching Systems manufactured by Ericsson Telecom AB. Generally, in most software applications, the use of more mode programming languages can reduce the number of source code statements required per task, which in turn can reduce software development time, support costs, anc costs for error corrections and other changes. However, as mentioned earlier, a significant amount of existing digital switching system software has been written in the "older" (e.g , PLEX) programming languages, and many of these programs have been in development over very long periods of time. As such, there can be an enormous amount of staff-hours and related costs already invested in the development of these programs. Consequently, it would be highly impractical fur many reasons (e.g., cost, reliability, delays, etc.) to replace the existing programs with programs re-written in one or more new programming languages. Therefore, a scheme is needed to replace current application software (e.g., programs written m PLEX) on a per program unit basis, while retaining the basic mechanisms needed for interoperability between the hardware units and software modules. Preferably, any scheme used for replacing the existing software should form part of an organization's normal support process flow for creating new software and/or updating existing software. Furthermore, such a software replacement scheme should consider the fact that future telecommunications systems will be required to be more heterogeneous with respect to the programming languages being used. In other words, the days of meeting customer requirements for single programming languages used m all applications and all processor environments are gone. The Capacity Modular Control (CMC) System is the newly developed version of the multi-central processor (multi-CP) AXE 10 Digital Switching System manufactured by Ericsson Telecom AB. The main purpose of the CMC System is to interconnect several CPs, which enables them to share the processing load and thereby increase the overall system capacity. A simplified block diagram of an exemplary CMC System (10) is shown in FIGURE 1 A. As shown, the individual CPs 12, 14, 16 are coupled together via an Inter-Processor Network (IPN) 18. The IPN also couples other types of processors together, such as the pair of Adjunct Processors (APs) 20, 22 shown. Typically, a telephony system CP has three mam components: (1) an executing processor; (2) a program and data store; and (3) a scheduling unit. For example, referring to FIGURE IB, each CP 12 (14, 16) in a CMC System include-, an executing processor 24, which executes instructions for both the application programs and operating system. Each CP also includes a program and data store 26 that is subdivided into different parts, each of which supports a known hardware entity or software function, such as job-handling, variable-handling, memory caches, etc. A scheduling unit 28 is also included m each CP, which schedules jobs in the correct order for the executing processor 24, and also communicates with other processors that support communications with peripherals and other processors in the system, such as, for example, with Input/Output Group (IOG) 30 or Regional Processor (RP) 32 via an RP Bus (RPB) 34. A problem with conventional and more recently developed central processor schemes (e.g., CMC) is that an executing processor in each C? (e.g., 12, 14, 16) executes applications m only one programming language. Also, as illustrated by the CMC scheme, each executing processor is associated with only one program and data store and scheduling unit. Consequently, in order to update or replace an existing programming language, the application software has to be rewritten for the same executing processor, or the application has to executed by a different executing processor in a different CP. Therefore, when combining different types of executing processors, some of them are likely to be only partly utilized. Furthermore, when a multi-CP system (e.g., CMC) is utilized for increased capacity, an operator has to allocate software to the different CPs in ord. r to maximize the system's capacity. However, in this case, the communication path between CPs acts as a bottleneck. U.S. Patent No. 5,452,456 to Mourey et al. descπbes an approach that uses different instruction sets for different parts of a program. As such, the main purpose of the approach described in the Mourey patent is to utilize a new processor architecture without having to recompile all of the software. However, the Mourey approach of using different languages in one program is not as efficier.t as an approach that would use one compiler and software architecture for the same programming language and source code As descnbed in detail below, the present mvention takes such an approach and also successfully resolves the above- described problems. SUMMARY OF THE INVENTION The preferred embodiment of the present invention provides a separate executing processor for each programming language in each CP. As such, each C in a multi-CP system utilizes a common program and data store and scheduling unit, which support two or more executing processors. Each executing processor can execute a different application using a different programming language Consequently, applications using older programming languages can be executed by the CPs, in addition to the same or different applications being executed with new programming languages. An important technical advantage of the present invention is that each executing processor can be more efficiently if not completely utilized. Another important technical advantage of the present invennon is that maximum capacity can be obtained from a single program and/or data store. Yet another important technical advantage of the present invention is that the executing processors are more language-specific than the scheduling units and program and data stores, which allows the use of specialized hardware support ana places special demands on the executing processors to operate more efficiently. The hardware support can be for sub-vaπable accessing, functional changes, file size alterations (e.g., for PLEX), fast context switching, function calls and efficienc access to function-local data (e.g., for Erlang), inheritance support, pointer manipulation and garbage collection (e.g., for Java), etc. Still another important technical advantage of the present invention is that for each high level language being executed, an appropriate assembly language can be used to reduce the source code volume, which reduces the bandwidth demand for program store reads, the demands on the cache volume, and the overall cost of the program. Still another important technical advantage of the present invention is that an executing processor used can be either off-the-shelf (out-sourced) or custom designed. For a common sourced processor, it is possible to purchase higher quality compilers, debuggers, etc. Yet another technical advantage of the present invention is that it is possible to combine program language flexibility (relatively easy to change from one programming language to another) with higher system capacity and overall cost- effectiveness. BRIEF DESCRIPTION OF THE DRAWINGS A more complete understanding of the method and apparatus of the present invention may be had by reference to the following detailed description when takeri in conjunction with the accompanying drawings wherein: FIGURE 1A is a simplified block diagram of an existing modular central processing system for a digital communications switching system; FIGURE IB is a simplified block diagram of a central processor in the modular central processing system shown in FIGURE 1 A; FIGURE 2 A is a simplified block diagram of a central processor, which can be used to implement a preferred embodiment of the present invention; FIGURE 2B is a simplified block diagram of a second central processor, which can be used to implement a second embodiment of the present invention; and FIGURE 3 is a block diagram of a scheduling unit that can be used in the exemplary central processors shown in FIGUREs 2A and 2B to implement the present invention. DETAILED DESCRIPTION OF THE DRAWINGS The preferred embodiment of the present invention and its advantages are b. st understood by referring to FIGUREs 1 -3 of the drawings, like numerals being used ior like and corresponding pans of the various drawings. Essentially, in accordance with a preferred embodiment of the present invention, a separate executing processor is provided for each programming language in each CP. As such, each CP in a multi-CP system utilizes a common program and data store and scheduling unit, which support two or more executing processors. Each executing processor can execute a different application using a different programming language Consequently, applications using older programming languages can be executed by the CPs, in addition to the same oi different applications being executed with new programming languages. Therefore, the older programming languages can be maintained along with the newe.- programming languages, or phased out slowly by the newer programming language-, over a period of time. Specifically, FIGURE 2A is a simplified block diagram of a CP 100A, which can be used as one "side" of a CP in a muln-CP digital switching system, m accordance with a preferred embodiment of the present invention. FIGURE 2B is a simplified block diagram of a second CP 100B, which can also be used as one "side" of such a CP, in accordance with a second embodiment of the present invention. However, although the exemplary embodiments shown in FIGUREs 2 A and 2B aie described with respect to a multi-CP digital switching system, the invention is nut intended to be so limited and can be implemented in any CP environment wheie programming language flexibility is desired. In FIGURE 2 A, exemplary CP 100A includes a scheduling unit 105, which is coupled to a plurality of RPs lOla-c via an RPB 103, and also to an I/O Group ar.d other communications devices (not shown) via anEthemet interface 104. An example of a specific type of such a scheduling unit is a Signal Processor Unit (SPU) that h-is been utilized for PLEX applications in Ericsson AXE 10 Digital Switching Systems. Each RP 101 a-c is coupled via a data connection 102a-c to a second RP. As such, lor this embodiment, CP 100A (e.g., A-side CP) can be duplicated for redundancy in a second CP (B-side CP) operating in a parallel synchronous mode. In accordance with the present invention, the scheduling unit 105 prepares tne numerous jobs to be performed by each of the executing processors 107, 114, 1 0 and 121, which enables the executing processors to execute their respective programs continuously. For example, most telecommunication applications divide "work" into numerous small jobs, tasks, and/or processes. This approach is advantageous from a software-structuring point of view since each call being processed is in itself a small job compared to the total amount of "work" being done. Furthermore, in a telephony environment, each call can be sub-divided into a number of smaller jobs Certain telecommunications programming environments, such as, for example, PLEX, Erlan.> and TelORB can support such applications that are sub-divided into a number of smaller jobs. However, the sub-division of "work" into a plurality of jobs can place special requirements on the scheduling mechanism used. The use of a specialized SPI J for PLEX applications the AXE Digital Switching Systems exemplifies such a requirement. As opposed to software scheduling for device processors, the demands made on scheduling mechanisms for central processor software used in telecommunication applications can be characterized as "moderate real-time" (i.e., response time on the order of milliseconds). For this embodiment, there are two main channels for daia and/or signal flow connected between each executing processor 107, 114, 120 and 121, and the scheduling unit 105. Each of these multi-channel connections .s characterized by arespective double-arrowed line I06a-d. One such channel (in 106 t, 106b, 106c or 106d) supports the flow of jobs to be executed (i.e., job starts) from the scheduling unit to the respective executing processor. The second such channel supports the flow of requests made from the respective executing processor to the scheduling unit. The multi-channel connections 106a-d can thus convey, for example, messages (signals), header pans, and data pans for RP messages and shon messages. For this exemplary embodiment, the requests made can be one of three type s (1 ) request for job, including message data (e.g., a PLEX buffered signal); (2) message sent; and (3) wait for message. The second and third request types can be used for programming languages that have active message reception capabilities. The scheduling unit 105 stores a "request for job" directly in a job queue (e.g , awaitmg execution by an executing processor). For example, one job queue can be used for stoπng multiple job requests in the scheduling unit for multiple executing processoi s. As such, addressing information included in each such job request can be transformed (by the scheduling unit) into a specific code that selects an executing processor, or more precisely, an instruction set to be used for that job. Alternatively, a job queαe located in the scheduling unit can be partitioned for separate executing processors, or a plurality of job queues can be used (e.g., one queue for each executing processor) When a "message sent" or "wait for message" request is received in th«; scheduling unit (sent from one of the executing processors), the scheduling unit preferably attempts to combine that request with a "request for job". The scheduling unit then stores the resulting combined request in a job queue (with the appropnate pnoπty level assigned). The function of combining a "message sent" or "wait for message" request with a "request for job" can be accomplished, for example, by conventional software or specialized hardware support (e.g., associative memoπesi. In scheduling a job request ("request for job"), the scheduling unit 105 can schedule an mdividualjob request m the queue so that it can break into an ongoing job or wait for an ongoing job to be completed. The "break into" type of request can be used, for example, as an interrupt, timer or time-slicing function. In that case, a second job request associated with a "break into" request is inserted in the job queue for scheduling, which essentially functions as a "return to interrupted job" The typical "older" programming languages (e , PLEX) do not support active message reception. As such, by sending a message to a higher pnority level, execution of the message at the lower pnoπty level is halted immediately and re-staned at the higher priority level. This arrangement places ceπain requirements on the speed and design of the scheduling unit used. On the other hand, many "newer" programming languages or telecommunication operating systems can readily implement more flexible scheduling principles than those implemented by the "older" programming languages As sue h, the "newer" languages do not support scheduling for different pπonty levels in the sense that ongoing jobs must be halted immediately when a higher priority level job is presented from the queue Conversely, in telecommunications applications, ihe "newer" programming languages are typically scheduled for execution in a ti e- slicing type of system, which ensures that no job is executed for more than a predetermined amount of time before another scheduled job event occurs. Consequently, as provided for by the present invention, scheduling of jobs for ihe newer programming languages preferably includes a mechanism for breaking into ongoing jobs, and ihen allows the interrupted jobs to continue at a later time. Specifically, an important component in the exemplary system 100A and 100B • which is used to implement the present invention, is the scheduling unit 105 At such , the scheduling unit 105 controls the flow of jobs being executed by the different executing processors 107, 114, 120, 121. In the preferred embodiment, one oi more executing processors (e.g , 107, 120) can be running Erlaπg applications, and one or more other executing processors (e.g , 114, 121 ) can be running JAVA applications In a different embodiment (e g , as shown in FIGURE 2B), one or more exe. ut g processors (e.g., 108) can be running PLEX applications in addition to those exe. uting processors running Erlang applications (e.g., 107) Notably, the present mveniion is not limited to the specific number of executing processors shown or to the exec ution of Erlang, PLEX or JAVA applications. The scheduling unit 105 can control the scheduling of up to several executing processors at a time. As such, each of the executing processors can execute a different application with a specific programming language, such as, for example, PLEX, JAVA, Erlang, Pascal, Perl, TelORB, C, C\ C τx , etc Notably, for example, the C type processors can be the type of C processors that are currently commercially available in the microprocessor market FIGURE 3 is a block diagram of a scheduling unit 200 that can be used as scheduling unit 105 m exemplary CP systems 100A and 100B (FIGUREs 2 A and 2B) to implement the present invention. The scheduling unit 200 stores a "request for j ob" directly a job queue 202 (e.g., awaiting execution by an executing processor) One job queue can be used for storing multiple job requests in the scheduling unit for multiple executing processors. As such, addressing information included in an address field in each such job request is transformed by the operating system and the scheduling unit into a specific code that selects an executing processor (e g , based on the programming language being executed by that processor), or more precisely, an instruction set to be used for that job. Alternatively, a job queue located in the scheduling umt can be partitioned for separate executing processors, or a plurality of job queues can be used (e.g., one queue for each executing processor). The job queue 202 includes a plurality of prioritized queues, which determine the scheduling of the job requests stored in the job queue For example, the highest pnontyjobs handled first by the scheduling umt are the debugging job requests scored m the debug queue 202a, the next level job requests handled are the high pnonty job requests stored in the high prioπty queue 202b, and so on in alphabetical order. As such, the number of prionty levels and, thus, the number of queues (e.g., 5) in the job queues 202 can vary depending on the specific design requirements imposed for the two or more programming languages use The scheduling unit 20Q sends th<: jobs residing in the job queues 202a-e to the appropriate (as addressed) executing proc essor 107, 114, 120, 121 in priority order (a to e). The scheduling unit sends a new j ob to the executing processor as soon as the previous job sent to that executing processor has been completed. The scheduling unit 200 also includes a plurality of "wan- for" queues 2 4a-e and "periodic/timed" job queues 206a-e. Similar to the job queues 202a-e, the " wait- for" and "period/timed" job queues are prioritized to handle jobs in alphabetical order (a-e) An "active message reception language" message queue 208 is include d for languages capable of active message reception (e.g., for Erlang). The scheduling unit 200 also includes a search mechanism (implemented by a conventional software and/or hardware scheme) for combining the messages stored in the "active message reception language" message queue 208 with the "waic-for" tasks stored in the "wait-for" queues 204a-e. As soon as there is an "active message reception language" message received in the message queue 208 (e.g., generated from a PLEX "send" statement and sent via input data line 215, or from an Erlang application via input data line 212) from an executing processor, which c;uι be combined with a "wait-for" request in the "wait-for" queue 204 (e.g., generated from a "receive" statement in an Erlang application via input data line 214), the scheduling unit deletes the message in the message queue 208 and the request in the "waii-for" queue 204a-e. The scheduling unit then sends the corresponding job tu the conesponding job queue 206a-e. Any executing processor (e.g., 107, 114, 120, 121) running any programming language can send a periodic call request or timed job request to peπodic/timed job queue 206a-e via an input data line 218. Also, an incoming message for non-active message reception languages (e.g., PLEX) can be sent to the job queues 202a-e via input data lines 210 and 213. The instruction processor (not shown) can send outgoing messages to an external processor via the representative ouφut data line 216, or receive incoming messages via the data lines 210, 212. The external processoi s (not - shown) can send messages to the CP 100(X), as shown, for example, m FIGURE 2B. Returning to FIGUREs 2 A and 2B, the exemplary CPs 100A and 10QB also include different levels of storage that form a memory hierarchy (e.g., those levels of storage nearest the processors are typically the fastest and smallest, the next levels are slower and larger, and so on). Some storage levels may be used as a cache for the next level. For example, CPs 10θA and 100B include a level 2 cache memory 109, vvhich (in these embodiments) is common to the executing processors 107, 114, 120, 121, etc. In the context of an Ericsson AXE Digital Switching System, a PLE- SPU including such a cache memory is referred to as an Instruction Processor Unit ( IPU) According to a predetermined cache policy, the cache memory 109 is used by each executing processor for relatively fast access to data (copied from main memory) that is cunentiy residing there, which minimizes the need to access main memory f r that data. The cache policy for the cache memory 109 is based on a number of factors. For example, although the processing capacities and clock frequencies of exec uting processors have increased significantly in recent years (and will probably continue to do so for the foreseeable near future), the access times for memories have not increased nearly so fast. Consequently, if that trend continues into the future, the pnmary processor design "bottlenecks" will be memory bandwidth, cache memory utilization, and cache latency (ability to lie hidden). However, in accordance with the present invention, if a cache's "hιt-r∑.te" is high enough, several executing processors can be combined to utilize one common main store (e.g., such as program stores 110 and 116). However, a viable alternative is to utilize a separate main store for each executing processor. Another viable alternative is to utilize a common main store (e.g., a program store 110 or 1 J 6) in combination with separate second level caches (e.g., 109) and first level cach s for each executing processor (e.g., as shown, a cache that is internal to each executing processor). As illustrated by FIGUREs 2A and 2B, the preferred embodiments utilize a common main store (e.g., 110, 116) and common second level cache (e.g , 109) for all executing processors, in combination with a separate first level (internal) cache for each executing processor. The latter two alternatives are more flexible than the first and do not require an operator to allocate additional software in order to obtain maximum capacity However, on the other hand, an operator may obtain maximum capacity using the first alternative with additional software allocations Also, as shown in the two embodiments illustrated by FIGURES 2A and 2B, the CPs 100A and 100B each include a common store 111 In these embodiments, the common stores 111 are utilized to store message data for all programming languages and/or executing processors being utilized (e , Erlang, PLEX, JAVA, etc ) Typically, the common stores 111 are used for storing relatively large message s In the embodiment of FIGURE 2A, the CP 100A includes a heap memory 117 which can be utilized for all of the programming languages involved (e.g., Erlang and JAVA). A separate stack (push-down list, LIFO storage) 118, 119 is utilized foi each programming language and or executing processor involved (e.g., 118 for Erlan , 119 for JAVA, etc.). Typically, there is one stack for each process, or m other words, many stacks for each programming language and/or processor involved Also, if the programming language supports threads, there is typically one stack for each thread. A common hardware support store 115 (FIGURE 2 A) is utilized for garbage collection (e g., administration and recycling of common heap memory 117) for all programming languages an Vor executing processors involved. Alternatively, as illustrated by the embodiment shown in FIGURE 2B, the CP 100B can include a data store 112 for one programming language and/or executing processor involved (e.g., for Erlang). Preferably, the data store 112 includes a .tack and heap memory structure for the Erlang or similar programming language. The CP 100B can also include a combined data store and reference (address) store 1 1 3 for PLEX and similar programming languages Notably, although the two embodin tents in FIGUREs 2 A and 2B show specific memory and data store structures, the/ are provided for illustrative purposes only. As such, if numerous different programming languages and executing processors are utilized m any embodiment of the present invention, common or separate cache memory, main memory, stacks, heaps, etc can be utilized for the programming languages and executing processors involved. Although a prefened embodiment of the method and apparatus of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiment disclosed, but is capable of numerous reanangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims: WHAT IS CLAIMED IS: 1. A central processor for a telephony system, comprising: a scheduling unit; and at least two executing processors coupled to said scheduling umt, a first executing processor of said at least two executing processors for executing a first application with a first programming language, and a second executing processor of said at least two executing processors for executing a second application with a ..econd programming language. 2. The central processor of Claim I, wherein said first programming language comprises PLEX and said second programming language comprises f AVA or Erlang. 3. The central processor of Claim 1, comprising a side of a central processor in a multi-central processor digital switching system. 4. The central processor of Claim 1 , further comprising a program store coupled to said at least two executing processors. 5. The central processor of Claim 4, further comprising a data store coupled to said at least two executing processors. 6. The central processor of Claim 1 , further compnsing a cache memory coupled to said at least two executing processors. 7. The central processor of Claim 4, further comprising a separate cache memory coupled to each of said at least two executing processors. 8. The central processor of Claim 1, further comprising a separate program store coupled to each of said at least two executing processors. 9. The central processor of Claim 1 , wherein said at least rwo executing processors further comprise a plurality of executing processors, said plurali t y of executing processors for executing a combination of JAVA, Erlang, PLEX and C programming languages. 10. A method for minimizing the effect of replacing central processor programming languages in a digital communications switching system, comprising: a first executing processor in a central processor executing a first application with a first programming language; and a second executing processor in said central processor executing a second application with a second programming language. 11. The method of Claim 10, further comprising the steps of. at least a third executing processor executing at least a third application with at least a third programming language; and said executing processors executing a combination of at least JAVA, Erlang, PLEX and C programming languages. 12. The method of Claim 10, further compnsmg the step of a common scheduling unit assigning a sequence of jobs associated with the step of executing said first application and the step of executing said second application 13. The method of Claim 10, wherein said first programming language comprises PLEX and said second programming language comprises JAVA or E.lang. 14. The method of Claim 10, further compnsmg the step of coupling a common program store to said first executing processor and said second executing processor. 15 The method of Claim 14, further compnsmg the step of coupling a common data store ro said first executing processor and said second executing processor. 16. The method of Claim 10, further comprising the step of coupling a common cache memory to said first executing processor and said second executing processor. 17. The method of Claim 14, further comprising the step of coupling a separate cache memory to each of said first executing processor and said ..econd executing processor. 18. The method of Claim 10, further comprising the step of coupling a separate program store to each of said first executing processor and said ..econd executing processor.

Inventors: LINNERMARK NILS OLA AXEL, LINNERMARK, NILS, OLA, AXEL
Applicants: ERICSSON TELEFON AB L M, TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
Application year: 1999
Main classification: G06F15
IPC codes: G06F9