SE9703132A0

SE9703132A0 - Software model for a distributed processor system

Info

Publication number: SE9703132A0
Application number: SE9703132A
Authority: SE
Inventors: Lars Ulrik Jensen
Original assignee: Ericsson Telefon Ab L M
Priority date: 1995-12-08
Filing date: 1997-08-29
Publication date: 1997-08-29
Also published as: AU1048897A; SE9504396D0; SE515348C2; WO1997022054A2; SE9504396L; WO1997022054A3; SE9703132D0; SE9703132L

Abstract

SAMMANFATTNING AV UPPFINNINGEN Ett dndamal med uppfinningen är att tillhandahalla en metod for automatisk aterhdmtning frail multipla permanenta fel i processorer i ett distribuerat processorsystem anvdnt i en applika- tionsmilja i ett telekomsystem som har hoga krav pa tillgdnglighet samtidigt som telekomsystemet skall medge systemunderhall, vare sig detta är planlagt eller ej. Ett annat dndamal med uppfinningen är att utnyttja tillgdngliga processorresurser samtidigt som uppfinningen medger en heterogen processormiljo, till faljd dels av infOrande av fly teknologi i ett system som vdxer med tiden och dels av de enskilda krav som stalls av olika delar av en applikation som kar pa processorsystemet. Annu ett dndamal med uppfinningen är att tillhandahalla en metod far snabb aterhdmtning i hdndelse av att flera processorer gar sander i ett distribuerat processorsystem som anvdnds i en telekomsystemmiljo genom att tillhandahalla en initial konfigu- rering av samtliga processorer och genom att tillhandahalla, for varje processor i systemet, en katastrofplan som skall anvdndas i hdndelse av att ifragavarande processor gar sander. En katastrofplan är det organ med vars hjdlp mjukvaruobjekt, som finns installerade pa en trasig processor, distribueras till . 25 ett antal processorer i systemet sa att lasten delas mellan . • • •• • processorerna. SUMMARY OF THE INVENTION An object of the invention is to provide a method for automatic recovery from multiple permanent errors in processors in a distributed processor system used in an application environment of a telecom system which has high accessibility requirements while allowing the telecom system to maintain system maintenance. is planned or not. Another object of the invention is to utilize available processor resources at the same time as the invention allows a heterogeneous processor environment, due in part to the introduction of flight technology in a system that grows with time and in part to the individual requirements of different parts of an application running on the processor system. Another object of the invention is to provide a method for rapid recovery in the event that several processors go sand in a distributed processor system used in a telecom system environment by providing an initial configuration of all processors and by providing, for each processor in the system, a contingency plan to be used in the event that the processor in question is sanding. An emergency plan is the body with the help of which software objects, which are installed on a broken processor, are distributed to. A number of processors in the system said that the load is divided between. • • •• • the processors.

Description

UPPFINNINGENS BENAMNING Mjukvarumodell for en distribuerat processorsystem SOKANDE Namn och adress. NAME OF THE INVENTION Software model for a distributed processor system APPLICANT Name and address.

Om ombud saknas ange aven Ert telefonnummer. If a representative is missing, also state your telephone number.

For juridisk person anges organisationsnummer. TELEFONAKTIEBOLAGET LM ERICSSON 126 25 Stockholm Organisationsnummer UPPFINNARE Namn och adress Lars Ulrik Jensen Erik Dahbergsgatan 55,115 57 Stockholm OMBUD Namn, adress och telefonnummer x Undertecknad sOkande befullmaktigar harmed nedanstaende upptagna svenska ombud aft fore- trada mig i alit som r6r denna patentansokning och i alit som ror det eventuellt beviljade patentet. For legal entity, state organization number. TELEFONAKTIEBOLAGET LM ERICSSON 126 25 Stockholm Organization number INVENTOR Name and address Lars Ulrik Jensen Erik Dahbergsgatan 55,115 57 Stockholm REPRESENTATIVE Name, address and telephone number x Signed Authorizing Officers have the following listed Swedish agents represent me in this patent as an attorney who r6 the patent that may have been granted.

Sokande befullmaktigar nedanstaende svenska ombud genom separat fullmakt. Applicants authorize the following Swedish agents by separate power of attorney.

DR LUDWIG BRANN PATENTBYRA AB Box 1344,751 43 UppsalaTel- 018-568900 Ombudets ref nrLM 6674SE/II BEGARAN OM PRIORITET Datum, land och ansokningsnummer 1995-12-08Sverige - 9504396-4 VID DEPOSITION AV MIKROORGANISM Depositionsmyndighet DepositionsdatumI Depositionsnr VID AVDELAD ELLER UTBRUTEN ANSOKNING StamansokningarI Begard lopdag 9504396-41995-12-08 BEGARAN OM ITSGRANSKNING Nyhetsgranskning av internationellt slag x x x x BILAGOR IBeskrivning, patentkrav och sammandrag i tre exemplar Uppsala 1997-08-29 AVGIFT ..6ritningari3exemplarOrt, datum O verlatelsehandlingkopiaorig.ml.stam—ans. DR LUDWIG BRANN PATENTBYRA AB Box 1344,751 43 UppsalaTel- 018-568900 The ombud's ref no. StamansokningarI Begard lopdag 9504396-41995-12-08 REQUEST FOR ITS REVIEW News review of an international type xxxx APPENDICESDescription, patent claims and summary in triplicate Uppsala 1997-08-29 FEE ..6 drawings in3 copies Place, date

Fullmaktkopian — — Sekvenslista pa diskett EPOs program Patent In Prioritetsbevis I K DR LUDWIG BRANN D Gi,v0 Cu, PATENTBYRA AB -,4,-- x 7 BETALNINGSSATT Ansokningsavgift 3.800 kr Ansokningsavgift med ITS-granskning 7.000 kr Tillaggsavgift, 100 kr for varje patentkrav utover tio,kr Diariebevis: 20 kr Postgiron Bankgiro x Underskrift Hans-1Ake Svanfeldt Check ri Kontant PostadressBesoksadressTelefonTelexTelefaxTelegramPostgiroBankgiro Box 505Valhallavagen 13608-782 25 001797808-666 02 86PATOREG1 56 84-45050-0241 rin-rnocn c ••• ••• •••••••: •••••••• •••••••• • •• • • • •• • • ••• •• •• ••• • • • • • ••• : ".• ••• •••••••• :•• ••• Mjukvarumodell for ett distribuerad processorsystem TEKNINSKT OMRADE Foreliggande uppfinning avser en mjukvarumodell for ett distri5 buerat, feltolerant, rekonfigurerbart processorsystem i ett telekommunikationsnat. Power of attorney copy - - Sequence list on diskette EPO's program Patent In Priority Certificate IK DR LUDWIG BRANN D Gi, v0 Cu, PATENTBYRA AB -, 4, - x 7 PAYMENT PAY Application fee SEK 3,800 Application fee with ITS review SEK 7,000 Additional fee, SEK 100 for each patent ten, SEK Diary certificate: SEK 20 Postgiron Bankgiro x Signature Hans-1Ake Svanfeldt Check in Cash Postal addressBesoksadressTelefonTelexTelefaxTelegramPostgiroBankgiro Box 505Valhallavagen 13608-782 25 001797808-666 02 86PATOREG1 5624-•50 •• • •••: ••••••••• •••••••• • •• • • • • • • ••• •• •• ••• • • • • • •••: " TECHNICAL FIELD The present invention relates to a software model for a distributed, fault-tolerant, reconfigurable processor system in a telecommunication network...................................

TEKNISK BAKGRUND I publika telekammunikations system finns manga olika processo- 10 rer som utfor olika uppgifter, sasom t ex overvakning av aktivitet pa abonnentlinjer, uppstallning och frigoring av forbindelser, trafikstyrning, systemunderhall och taxering. Grupper av processorer är hopkopplade med varandra med hjalp av ett nat som at skilt frAn telekommunikationsnatet eller som bildar en 15 del av detta. I moderna telekommunikationsnat finns natelement, sasom t ex en valjare, en databas, en processor, som är distribuerade pa flera fysiska element i det fysiska natet som bildar telekommunikationsnatet. FOr en applikation sasom t ex POTS (Plain Old Telephony Service), GSM (Globalt System for Mobil- 20 kommunikation), VLL (virtuella hyrda forbindelser), BISDN (bredbandigt digitalt nat med integrerade tjanster) set en distribuerad processor eller en distribuerad databas ut som en enda enhet. De distribuerade enheterna sags vara transparenta ur distributionssynpunkt. TECHNICAL BACKGROUND In public telecommunications systems, there are many different processors that perform various tasks, such as monitoring activity on subscriber lines, setting up and releasing connections, traffic control, system maintenance and taxation. Groups of processors are interconnected by means of a network which is separate from the telecommunication network or which forms part of it. In modern telecommunication networks there are network elements, such as a selector, a database, a processor, which are distributed on several physical elements in the physical network which form the telecommunication network. For an application such as POTS (Plain Old Telephony Service), GSM (Global System for Mobile Communications), VLL (virtual leased lines), BISDN (broadband digital night with integrated services) set up a distributed processor or a distributed database as a single entity. The distributed units are said to be transparent from a distribution point of view.

• • •• • • • • • • • •• • •• • • • • • • Ett huvudkrav som stalls pa processorbaserade styrsystem for publika telekommunikationssystem är systemtillganglighet. Med detta avses att systemet skall vara tillgangligt for att betjana sina anvandare. I telefonsystemet AXE-10 tillats systemet vara otillgangligt endast tva timmar under 40 Ai.. Omvandlat • till minuter per ar motsvarar detta ca 3 minuterfar. Moderna .. ••• •• • •• ••• • • • • telekommunikationssystem har avsevart hogre krav pa tillgang- ••• • ••• • •• 41;•••••••: • • • •••••••• •• •••••••• •• • •• •• •• ••• • •• •• •• • ••• 2 : ••• : •••••••• :•• ••• lighet. Icke desto mindre krdvs av moderna telekommunikationssystem att planerat underhallsarbete, som kan ta rang tid, skall kunna utforas med langa tidsintervall, t ex med tidsintervall i storleksordningen ca 1 manad. • • •• • • • • • • • •• • •• • • • • • • A major requirement placed on processor-based control systems for public telecommunications systems is system availability. This means that the system must be accessible to serve its users. In the AX-10 telephone system, the system is allowed to be inaccessible for only two hours below 40 Ai. Converted • to minutes per year, this corresponds to approximately 3 minutes. Modern .. ••• •• • •• ••• • • • • telecommunication systems have met higher demands on access- ••• • ••• • •• 41; •••••••: • • • • ••••••• •• •••••••• •• • •• •• •• ••• • •• •• •• • ••• 2: •••: •••• ••••: •• ••• lighet. Nevertheless, modern telecommunication systems require that planned maintenance work, which can take time, be able to be carried out with long time intervals, for example with time intervals of the order of about 1 month.

Allmdnt sett efterstrdvas bade forbdttrad systemtillganglighet och ldngre medeltid mellan reparation (MTTR). Lang medeltid mellan reparation är onskvdrt och medger att reparation kan utforas pa arbetsdagar (mandag till fredag) och pa arbetstid (fran 08.00 till 17.00) samt medger schemalagt underhall. Dessa krav leder till att telekommunikationssystemet maste kunna tolerera att en processor gar ned och att, innan den har reparerats, dven en andra processor tillats att gá ned men att systemet skall kunna tolerera detta och fortfarande vara 15 driftsdugligt. I det vArsta fallet, och innan de forsta andra havererade processorerna har reparerats, skall systemet kunna tolerera att dven en tredje, fjdrde och tillkommande processorer gar ned, men att systemet fortfarande skall vara tillgdngligt trots de trasiga processorerna. In general, both improved system availability and longer repair time (MTTR) are sought after. Long average time between repairs is undesirable and allows repairs to be carried out on working days (Monday to Friday) and during working hours (from 08.00 to 17.00) and allows scheduled maintenance. These requirements mean that the telecommunication system must be able to tolerate a processor going down and that, before it has been repaired, a second processor is allowed to go down but that the system must be able to tolerate this and still be operational. In the worst case, and before the first other failed processors have been repaired, the system must be able to tolerate a third, fourth and additional processors going down, but the system must still be accessible despite the broken processors.

Amerikanska patentskriften 4 710 926 avser ett felaterhdmtningsforfarande i ett distribuerat processorsystem enligt vilket forfarande reservprocessorer tar over trasiga processorers funktioner. En reservprocessor tjdnstgor som ersdttare fOr en 25 eller flera aktiva processorer. Ndr en reservprocessor tas i ••• • •• • drift tjdnstgor den inte ldngre sasom reservprocessor for flagon • •• •annan processor i systemet. Vid felaterhdmtning overfors alla • •• • •• • • •funktioner som exekverar pa den trasig processorn till reserv- • • •processorn. Den gamla reservprocessorns funktion att vara re- " • servprocessor overfors till en andra reservprocessor i • ". •• • systemet. ". •• • •• • • • • •• ••• • 4• • • 006 000• •64•• • • • • ••006 3 Detta kanda system kraver saledes tva eller flera reservprocessorer. Nar en reservprocessor är inaktiv utfOr den inte nagra jobb. Nar den aktiveras borjar den utfora jobb - forutsatt att den fungerar d v s inte uppvisar nagra fel. Det är nodvandigt 5 att kora testprogram som verifierar att reservprocessorerna fungerar. Detta omnamns dock inte patentskriften. U.S. Pat. No. 4,710,926 relates to an error prevention method in a distributed processor system according to which method backup processors take over the functions of broken processors. A backup processor serves as a replacement for a 25 or more active processors. When a spare processor is taken into service, it no longer serves as a spare processor for the flag • •• • another processor in the system. In case of error handling, all • •• • •• • • • functions executing on the broken processor are transferred to the backup • • • • processor. The function of the old backup processor to be a "• server processor is transferred to a second backup processor in •". •• • the system. ". •• • •• • • • • •• ••• • 4 • • • 006 000 • • 64 •• • • • • •• 006 3 This known system thus requires two or more spare processors. When a spare processor is when it is activated, it does not perform any jobs. When activated, it starts performing jobs - provided it works, ie does not show any errors. It is necessary to run test programs that verify that the backup processors are working. However, this is not renamed the patent specification.

Det amerikanska patentet 4 412 281 beskriver ett distribuerat, feltolerant, rekonfigurerbart signalbehandlingssystem som inne- 10 fattar manga identiska, med varandra forbundna sub-systemelement som delar pa det stora behandlingsjobbet. Sub-systemelementen är redundant hopkopplade med varandra med dubbla bussar. Vissa sub-systemelement tjanstgor som reservsystemelement och är redo ta over de jobb som utfors pa ett trasigt sub- 15 systemelement. Ett reservsub-systemelement har alien till uppgift att utfora kontroll av alla de egna funktionerna for att verifiera att dessa fungerar. Genom att periodiskt rotera reservsub-systemelement och aktiva sub-systemelement sakerstaller ett distribuerat operativsystem att samtliga sub-systemelement 20 utfor den namnda kontrollen av de egna funktionerna, varvid Aven mindre fel kan detekteras. Trasiga element i sub-systemet tas ur drift och ersatts med ett reservelement utan att systemet gar ned. . ?5 Signalbehandlingssystemet anvander saledes reserv sub-system- • • •• • element som inte deltar i de overgripande behandlingsuppgifter- • • • • •• • 66 • • • • • • .. • :•() kontaktdonadress associeras med en virtuell adress, som ersat- ." •• •ter kontaktdonadressen nar ett feltillstand detekteras. ". na. Den meted som anvands for rekonfigurering nar ett trasigt element detekteras och byts ut mot ett reservelement, utnyttjar distinkta kontaktdonadresser fOr varje element i systemet. En ••• •••• •••I: .41% •••• •••• •••• • • • • • • • • •• • • •• ••• • • ••• • • • • • • ••• 4 : ..• : •••• •• :•• ••• SAMMANFATTNING AV UPPFINNINGEN Ett dndamal med uppfinningen är att tillhandahalla en metod for automatisk aterhdmtning frail multipla permanenta fel i processorer i ett distribuerat processorsystem anvdnt i en applika- 5 tionsmilja i ett telekomsystem som har hoga krav pa tillgdnglighet samtidigt som telekomsystemet skall medge systemunderhall, vare sig detta är planlagt eller ej. U.S. Patent 4,412,281 discloses a distributed, fault-tolerant, reconfigurable signal processing system that includes many identical, interconnected subsystem elements that share the major processing job. The sub-system elements are redundantly connected to each other by double buses. Some subsystem elements serve as backup system elements and are ready to take over the jobs performed on a broken subsystem element. A spare subsystem element has the task of alien performing control of all its own functions to verify that they work. By periodically rotating spare subsystem elements and active subsystem elements, a distributed operating system ensures that all subsystem elements 20 perform the said control of their own functions, whereby even minor errors can be detected. Broken elements in the sub-system are taken out of service and replaced with a spare element without the system going down. . The signal processing system thus uses spare sub-system elements that do not participate in the overall processing tasks. • • • • •• • 66 • • • • • • .. •: • () connector address is associated with a virtual address, which replaces the "." • connector address when a fault condition is detected. ". na. The method used for reconfiguration when a broken element is detected and replaced with a spare element utilizes distinct connector addresses for each element in the system. En ••• •••• ••• I: .41% •••• •••• •••• • • • • • • • • • • • •• ••• • • ••• SUMMARY OF THE INVENTION An object of the invention is to provide a method for automatic recovery from multiple permanent defects in processors in a single invention............................... distributed processor system used in an application environment in a telecom system that has high accessibility requirements while the telecom system must allow system maintenance, whether this is planned or not.

Ett annat dndamal med uppfinningen är att utnyttja tillgdngliga 10 processorresurser samtidigt som uppfinningen medger en heterogen processormiljo, till faljd dels av infOrande av fly teknologi i ett system som vdxer med tiden och dels av de enskilda krav som stalls av olika delar av en applikation som kar pa processorsystemet. Another object of the invention is to utilize available processor resources at the same time as the invention allows a heterogeneous processor environment, due in part to the introduction of flight technology in a system that grows with time and in part to the individual requirements set by different parts of an application. on the processor system.

Annu ett dndamal med uppfinningen är att tillhandahalla en metod far snabb aterhdmtning i hdndelse av att flera processorer gar sander i ett distribuerat processorsystem som anvdnds i en telekomsystemmiljo genom att tillhandahalla en initial konfigu- 20 rering av samtliga processorer och genom att tillhandahalla, for varje processor i systemet, en katastrofplan som skall anvdndas i hdndelse av att ifragavarande processor gar sander. En katastrofplan är det organ med vars hjdlp mjukvaruobjekt, som finns installerade pa en trasig processor, distribueras till . 25 ett antal processorer i systemet sa att lasten delas mellan . • • •• • processorerna. Another object of the invention is to provide a method for rapid recovery in the event that several processors go sand in a distributed processor system used in a telecom system environment by providing an initial configuration of all processors and by providing, for each processor in the system, a disaster plan to be used in the event that the processor in question goes sand. An emergency plan is the body with the help of which software objects, which are installed on a broken processor, are distributed to. A number of processors in the system said that the load is divided between. • • •• • the processors.

• • • •• • •• • • • • • Annu ett dndamal med uppfinningen är att tillhandahalla nya katastrofplaner for systemet med fungerande processorer, av vilka " • :*10 nagra pa sig kan ha installerade mjukvaruobjekt fran en trasig • ". •• •processor, for att pa sã sdtt farbereda systemet for snabb ". • • • • •• • • • • • ••• • •• •• • • •• : • •• •• •• *.* •• • • ••• ..• •••• • • • : •• • • •• •••••••• •• •• •• •• • •• •• •• •• • :•• •• • • ••• ••• aterhamtning i handelse av att annu en processor i systemet gar sander. Another object of the invention is to provide new contingency plans for the system with working processors, of which "•: * 10 may in themselves have installed software objects from a broken •". •• • processor, so as to colorize the system too fast ". • • • • •• • • • • • ••• • •• •• • • ••: • •• •• •• *. * •• • • ••• .. • •••• • • •: •• • • •• •••••••• •• •• •• •• • •• •• •• •• • : •• •• • • ••• ••• recovery in the act of annu a processor in the system goes sander.

Annu ett andamal med uppfinningen är att tillhandahalla en me- 5 tod av ovanstaende slag vilken tar tillbaka systemet till dess ursprungliga konfigurering av processorer och mjukvaruobjekt nar systemets trasiga processor eller trasiga processorer efter reparation eller utbyte satts in i systemet igen. 10 Annu ett andamal med uppfinningen är att tillhandahalla en mjukvarumodell som medger att mjukvaruobjekt kan flyttas frail en trasig processor till en fungerande processor genom att mjukvaruobjekten omstartas pa den fungerande processorn. En mjukvarumodell kan ocksa dada ett mjukvaruobjekt som finns in- 15 stallerat pa en processor och kan omstarta mjukvaruobjektet pa en reparerad, tidigare trasig, processor som har satts tillbaka i systemet. Det sistnamnda andamalet intraffar i forsta hand nar systemet atergar till sin initial konfigurering och det pa de fungerande processorerna finns installerade objekt som skall 20 lamnas tillbaka till de reparerade processorerna. Another object of the invention is to provide a method of the above kind which takes the system back to its original configuration of processors and software objects when the system's broken processor or processors after repair or replacement have been reinserted. Another object of the invention is to provide a software model which allows software objects to be moved from a broken processor to a working processor by restarting the software objects on the working processor. A software model can also kill a software object that is installed on a processor and can restart the software object on a repaired, previously broken, processor that has been put back in the system. The latter second occurs primarily when the system returns to its initial configuration and the objects installed on the operating processors are to be returned to the repaired processors.

I enlighet med uppfinningen skapas en modell av telekommunikationssystemet, vilken modell innefattar en hardvarumodell av de styrande processorerna och av den styrda hArdvarutrustningen 25 samt aven en mjukvarumodell som stoder och passar i hardvarumo- • • " • dellen i telekommunikationssystemet. In accordance with the invention, a model of the telecommunication system is created, which model comprises a hardware model of the controlling processors and of the controlled hardware equipment 25 as well as a software model which stands and fits in the hardware model of the telecommunication system.

• • • • •• • •• • • • • I enlighet med uppfinningen anvands en forsta algoritm for att rakna ut katastrofplanerna for var och en av de fungerande pro- " • cessorerna antingen med ledning av den initiala konfigurationen . . eller med ledning av nagon av de konfigurationer som forekommer efter det att annu en processor har gatt sander. ••• • • ••• ••• • • • • • • 41.0 • • •• ••• • ••• • • • • • • ••• 6 *.* : ..• : •••• •••• :•• ••• I enlighet med uppfinningen anvands en andra algoritm som med ledning av en aktuell konfiguration beraknar en deltakonfiguration, som out den tillampas pa den aktuella konfigurationen, ger 5 tillbaka den initiala konfigurationen av systemet. In accordance with the invention, a first algorithm is used to unravel the contingency plans for each of the operating processors either by the initial configuration. of any of the configurations that occur after a processor has been sanded. ••• • • ••• ••• • • • • • 41.0 • • •• ••• • ••• • • • • In accordance with the invention, a second algorithm is used which, on the basis of a current configuration, calculates a delta configuration, which out the applied to the current configuration, returns the initial configuration of the system.

I den mjukvarumodell som anvands for mjukvaruobjekten finns inga konfigurationsberoenden inkapslade i mjukvaruobjekten vilket gor att mjukvaruobjekten kan flyttas fran en processor till 10 en annan i vilken processorkonfiguration som heist. In the software model used for the software objects, there are no configuration dependencies encapsulated in the software objects, which means that the software objects can be moved from one processor to another in which processor configuration is hoisted.

KORT BESKRIVNING AV RITNINGARNA En belysande utforingsform av uppfinningen kommer att beskrivas 15 nedan i anslutning till de bifogade ritningarna, i vilka . BRIEF DESCRIPTION OF THE DRAWINGS An illustrative embodiment of the invention will be described below in connection with the accompanying drawings, in which.

•• . • • • • •• • • • Z • • " • • •• • • • • • Fig. ••. • • • • •• • • • Z • • "• • •• • • • • • Fig.

Fig. FIG.

Fig. 1 2 3 4 •• • • • • är ett blockschema som visar ett distribuerat processorsystem i en initial konfiguration, är ett blockschema som visar processorsystemet i Fig. 1 i en aktuell konfiguration efter det att en av processorerna gatt sonder, är ett blockschema av processorsystemet i Fig.1 i en andra aktuell konfiguration efter det att tva processorer Ott sOnder, är ett flodesschema som visar metoden i enlighet med uppfinningen, 7 ••• •• •• • • •• : • •• •• • ••• •• • • ••• ••• •••• • • • : • • • • •• • • • • •• •• • It • • •• • • • •• • • • • • •••• •• • • ••• ••• Fig. är ett blockschema av ett distribuerat processorsys- tem i vilket vissa av processorerna styr hardvaruutrustning, 5 Fig. 6Aär en schematisk vy av ett modulariserat mjukvaruob- jekt, Fig. 6B-D är blockscheman av visande tre olika typer av mjukvaruobjekt, 10 Fig. 7är ett blockschema som visar hur hardvaru- och mjuk- varumodellerna i enlighet med uppfinningen passar i hop i en enda modell av telekommunikationssystemet, och 15 Fig. 8är ett blockschema som visar hardvarumodellen i en- lighet med uppfinningen. Fig. 1 2 3 4 •• • • • • is a block diagram showing a distributed processor system in an initial configuration, is a block diagram showing the processor system in Fig. 1 in a current configuration after one of the processors has probed, is a block diagram of the processor system in Fig.1 in a second current configuration after two processors Ott sOnder, is a flow chart showing the method in accordance with the invention, 7 ••• •• •• • • ••: • •• •• • ••• •• • • ••• ••• •••• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Fig. Is a block diagram of a distributed processor system in which some of the processors control hardware equipment; Fig. 6 is a schematic view of a modularized software object; 6B-D are block diagrams showing three different types of software objects, Fig. 7 is a block diagram showing how the hardware and software models according to the invention fit together in a single model of the telecommunication system, and Fig. 8 is a block diagram showing the hardware model in accordance with the invention.

DETALJERAD BESKRIVNING AV UPPFINNINGEN I Fig. 1 visas ett antal distribuerade processorer Pl, P2, P3 20 och P4 vilka kommunicerar med varandra over ett nat Ni. Processorerna bildar del av ett ej visat telekommunikationsnat. Natet Ni kan bilda en del av det namnda ej visade telekommunikationsnatet. Varje processor innehaller en processorenhet PE och mine M. Mjukvaruobjekt 1, 2, 3 ... 18 är installerade pa pro- 25 cessorerna; objekten 1, 2, 3 pa processor P1, objekten 4-7 pa • • • •• • • • • • • •• • •• • • • • • Mjukvaran for en applikation som k6r i telekommunikationsnatet innefattar mjukvaruobjekt (Fig. 6B-D), vilka ingar i mjukvaru- . moduler (Fig. 6A). De modulariserade mjukvaruobjekten är allo- • • kationsoberoende objekt vilka kan forflyttas fritt mellan pro- cessorerna. Ett modulariserat mjukvaruobjekt är oberoende av processor P2, objekten 8-12 pa P3 och objekten 13-18 pa P4. 8•• •• • •• ••• • • • • • 000 000 0000 •• • • • • ••000 ::• • OS•• • • •• 000000.0 00 • ovriga modulariserade mjukvaruobjekt. Ett mjukvarurobjekt innehailer typiskt en process och persistent data. Persistent data är data som overlever en omstart av mjukvaruobjektet. Mjukvaruobjekt kan kommunicera med varandra. Ett av en applikation 5 begart jobb involverar typiskt manga mjukvaruobjekt pa olika processorer och exekveras av vissa eller av alla processer. Applikationen kanner inte till hur mjukvaruobjektena är distribuerade pa de olika processorerna. Modulariserat persistent data kan vara lagrat i en databas. PA samma satt som processor- 10 systemet är distribuerat kan ocksa databasen vara distribuerad Over ett antal minnen M pA manga processorer, fOretradesvis pa minnena i samtliga processorer Pl, P2, P3 och P4. Dessa databaspartitioner betecknas DB1, DB2, DB3 och DB4 och innefattar ett arbetsminne (RAM). [Jr en applikations synpunkt är databa- 15 sens distribuerade natur transparent. Persistent data maste kunna lagras pa sAker satt. Detta kan Astadkommas genam konventionell backup-teknik, t ex genom att lagra datat pa en skiva. Ett nytt och f6redraget alternativ är emellertid att lagra en spegelkopia av varje modulariserat mjukvaruobjekt i en databas- 20 partition pa en processor som är skild fran den pa vilken objektet är installerat. Narmare bestAmt lagras spegelkopian av vane modulariserat mjukvaruobjekt i databaspartitionen pa den processor som utpekas i katastrofplanen for den processor pa vilken det modulariserade mjukvaruobjektet, originalet, exekve- 25 rar. PA detta satt kan kopior av det modulariserade persistenta . . • • ••datat lagras pa sAkert sAtt pa en annan processor i hAndelse av . • den processor pa vilken originalet finns lagrat gar sander. 4 • • • • • . • Det satt pa vilket objekten 1-18 är distribuerade pa processo- . • . 30 rerna P1-P4 kallas den initiala konfigureringen av det distri- • • .. • .. • • • • • • • • • • • • • 8 • • • • • * • buerade processorsystemet och visas i bifogade Tabell 1, ur • ••• • ••••••••••••:••••••••.••••••• ••••••••••• • •• ••••••••••••••• ••• 9 :..*:•••••••••:•• ••• vilken framgar att objekten 1, 2 och 3 är installerade pa pro- cessorn Pl. DETAILED DESCRIPTION OF THE INVENTION Fig. 1 shows a number of distributed processors P1, P2, P3 and P4 which communicate with each other over a night Ni. The processors form part of a telecommunication network (not shown). The network Ni can form part of the named telecommunication network not shown. Each processor contains a processor unit PE and mine M. Software objects 1, 2, 3 ... 18 are installed on the processors; objects 1, 2, 3 on processor P1, objects 4-7 on • • • •• • • • • • • • • • • • • • • • • The software for an application running in the telecommunication network includes software objects (Fig. 6B -D), which ings in software-. modules (Fig. 6A). The modularized software objects are • • allocation-independent objects that can be moved freely between the processors. A modularized software object is independent of processor P2, objects 8-12 on P3 and objects 13-18 on P4. 8 •• •• • •• ••• • • • • • 000 000 0000 •• • • • •• 000 :: • • OS •• • • •• 000000.0 00 • other modularized software objects. A software object typically contains a process and persistent data. Persistent data is data that survives a reboot of the software object. Software objects can communicate with each other. One job requested by an application typically involves many software objects on different processors and is executed by some or all of the processes. The application does not know how the software objects are distributed on the various processors. Modularized persistent data can be stored in a database. In the same way as the processor system is distributed, the database can also be distributed over a number of memories M on many processors, preferably on the memories in all processors P1, P2, P3 and P4. These database partitions are designated DB1, DB2, DB3, and DB4 and include a working memory (RAM). From an application point of view, the distributed nature of the database is transparent. Persistent data must be able to be stored securely. This can be achieved through conventional backup technology, for example by storing the data on a disk. However, a new and preferred alternative is to store a mirror copy of each modularized software object in a database partition on a processor separate from the one on which the object is installed. More specifically, the mirror copy of habitual modularized software object is stored in the database partition of the processor designated in the disaster plan of the processor on which the modularized software object, the original, executes. In this way, copies of the modularized can be persistent. . • • •• the data is stored securely on another processor in the event of. • the processor on which the original is stored is running. 4 • • • • •. • The way in which objects 1-18 are distributed on the process. •. P1-P4 is called the initial configuration of the distributed processor system and is shown in the attached Table 1, ur • ••• • •••••••••••••: ••••••••. ••••••• ••••••••••• • •• • •••••••••••••• ••• 9: .. *: •••••••••: •• ••• which shows that objects 1, 2 and 3 are installed on processor Pl.

Den initiala konfigureringen far inte fOrsvinna om flagon pro-5 cessor gar sander. Av denna anledning lagras den initiala konfigurationen och spegelkopian av denna pa det ovan beskrivna sattet. I stallet for att implementera den initiala konfigurationen i form av en tabell kan den implementeras i form av sã kallade par. Exempelvis motsvarar paren (1,1), (1,2), (1,3) den 10 information som framgar ur den forsta raden i Tabell 1. The initial configuration must not disappear if the flag processor 5 sander. For this reason, the initial configuration and the mirror copy of it are stored in the manner described above. Instead of implementing the initial configuration in the form of a table, it can be implemented in the form of so-called pairs. For example, the pairs (1,1), (1,2), (1,3) correspond to the information that appears from the first row in Table 1.

For att aterhamtningstiden fOr processorsystemet, och darfor aven av telekommunikationssystemet, skall vara kort om en processor gar sander skall det finna en katastrofplan for varje 15 processor som gar solider. Eftersom man inte kan forutse vilken processor som gar sander maste det finnas en katastrofplan for varje processor. En katastrofplan innehaller direktiv avseende de processorer till vilka mjukvaruobjekten pa den trasiga processorn skall flyttas. En katastrofplan, visad i Tabell 2, 20 utpekar de processorer till vilka de pa processorn P1 installerade objekten skall flyttas i handelse av att processorn P1 gar sOnder. En annan katastrofplan innehaller information som talar om vart de pa processorn P2 installerade objekten skall flyttas om P2 gAr solider. Pa likartat satt finns en katastrofplan som . 25 skall foljas om processor P3 gar sander. Denna katastrofplan . • • •• •visas i Tabell 4. Slutligen finns en katastrofplan, Tabell 5, •som tar hand om det fall som intraf far i handelse av att pro- • • •• • •• • . • •cessor P4 gar sonder. In order for the recovery time for the processor system, and therefore also for the telecommunication system, to be short if one processor is running, there must be a disaster plan for each processor running solid. Since it is not possible to predict which processor will go sandy, there must be a disaster plan for each processor. An emergency plan contains directives regarding the processors to which the software objects on the broken processor are to be moved. A disaster plan, shown in Table 2, 20 designates the processors to which the objects installed on the processor P1 are to be moved in the event that the processor P1 breaks down. Another disaster plan contains information that tells you where to move the objects installed on processor P2 if P2 is solid. Similarly, there is a disaster plan that. 25 must be followed if processor P3 is sanding. This disaster plan. • • •• • is shown in Table 4. Finally, there is a disaster plan, Table 5, • which takes care of the case that occurs in the act of pro- • • •• • •• •. • • cessor P4 gar without.

• . • Processor P1 gar sonder . . •. • Processor P1 gar without. .

Antag, att processor P1 gar sonder. Processorsystemet maste aterhamta sig snabbt fran felet och darfor skall de pA proces- ••• • • ••• 10 SID • • •• ••• II 4• ••• • • • •• •• • •• • 4.0 • • ••• • t ••■•• • II • • • • • • I •• • • • • •• 00 • IS • • • • • • •• • • • • • •••• •• • • ••• • • sorn P1 installerade mjukvaruobjekten 1, 2, 3 flyttas over till processorerna P2 och P4 i enlighet med katastrofplanen for Pl. Narmare bestamt skall mjukvaruobjekten 1 och 3 flyttas till processorn P2 och mjukvaruobjektet 2 skall flyttas till proces- 5 sorn P4. Detta astadkoms genom att mjukvaruobjekten 1-3 tas bort fran processorn P1 och genom att man pa processorn P2 skapar och startar mjukvaruobjekten 1, 3 och pa processorn P4 skapar och startar mjukvaruobjektet 2. Detta kraver givetvis att exekveringskapacitet finns tillganglig pa processorerna P2 10 och P4. Finns inte sadan kapacitet tillganglig kan systemet inte aterhamta sig fran processorfelet. I det foljande antas att den nodvandiga processorkapaciteten finns tillganglig och att systemet saledes aterhamtar sig fran felet. Systemet kommer nu att ha den kofiguration som visas i Fig. 2 och Tabell 6. Utga- 15 ende fran denna konfiguration, vilken nu kallas den aktuella konfigurationen, maste nya katastrofplaner skapas for att systemet snabbt skall kunna aterhamta sig om nagon av de ovriga processorerna gar sander. For detta andamal framstalls nya katastrofplaner vilka ger direktiv om till vilka processorer de 20 pA en trasig processor installerade mjukvaruobjekten skall flyttas. Eftersom man inte kan forutsaga vilken av de tre driftsdugliga processorerna P2-P4 som kommer att ga sonder är det nodvandigt att skapa katastrofplaner for var och en av de driftsdugliga processorerna. Tabell 8 är den nya katastofplanen . 5 (CP-P2') for processor P2, Tabell 9 den nya katastrofplanen • • •• • (CP-P3') for processor P3 och Tabell 10 den nya katastrofplanen • • • •(CP-P4') for processor P4. Assume that processor P1 is probing. The processor system must recover quickly from the error and therefore they must on the process ••• • • ••• 10 SID • • •• ••• II 4 • ••• • • • • • • • • •• • 4.0 • • ••• • t •• ■ •• • II • • • • • • I •• • • • •• 00 • IS • • • • • • •• • • • • • •••• •• • •••• • • sorn P1 installed the software objects 1, 2, 3 are moved to the processors P2 and P4 in accordance with the disaster plan for P1. More specifically, the software objects 1 and 3 are to be moved to the processor P2 and the software object 2 is to be moved to the processor P4. This is achieved by removing the software objects 1-3 from the processor P1 and by creating and starting the software objects 1, 3 on the processor P2 and on the processor P4 creating and starting the software object 2. This of course requires that execution capacity is available on the processors P2 10 and P4 . If such capacity is not available, the system cannot recover from the processor error. In the following, it is assumed that the necessary processor capacity is available and that the system thus recovers from the error. The system will now have the co-configuration shown in Fig. 2 and Table 6. Based on this configuration, which is now called the current configuration, new disaster plans must be created so that the system can quickly recover from any of the other processors. gar sander. To this end, new contingency plans are being produced which provide directives as to which processors the software objects installed 20 pA a broken processor are to be moved. Since it is not possible to predict which of the three operational processors P2-P4 will provide probes, it is necessary to create disaster plans for each of the operational processors. Table 8 is the new disaster plan. 5 (CP-P2 ') for processor P2, Table 9 the new disaster plan • • •• • (CP-P3') for processor P3 and Table 10 the new disaster plan • • • • (CP-P4 ') for processor P4.

• • •• . • • • • • • • PA samma satt som de ursprungliga katastrofplanerna lagras de • - • :°310 nya katastrofplanerna och deras spegelkopior pa det ovan be- • skrivna sattet. ••• ••••• : •••••••: •••••••• •••••••• ••• • •• • • • •• •• • •• • •• •• ••• • • • •• • •• •• •• • • • ••• • • 11 • •• • •• •• •••• •• Det bor observeras att framstallningen av nya katastrofplaner for den aktuella konfigurationen sparar minne jamfort med det foljande teoretsikt tankbara schema: antag att systemet bestAr av fyra processorer och att systemet är sá designat att det to- 5 lererar att tvA processorer gAr sonder. Eftersom man inte kan forutse vilken processor som gAr sonder forst och vilken processor gAr sonder som nummer tvA, mAste man skapa lika mAnga katastrofplaner som antalet olika satt pA vilket tvA element kan valjas ur en grupp av fyra element. Dessa katastrofplaner 10 mAste lagras i databasen. SAledes mAste tjugofyra katastrofplaner skapas och lagras. Denna lagring kraver mycket minnesutrymme. Minnesutrymmet vaxer snabbare an exponentiellt med antalet processor systemet kan tolerera gá sonder. 15 Under perioden frAn det att systemet Aterhamtat sig fram till dess att nya katastrofplaner utarbetats och lagrats i databasen är systemet sArbart. Under denna period fAr inga processorer gA sander. Skulle en processor haverera under denna period kommer systemet inte att vara tillgangligt. .2 • •• • : • Nar en processor PI efter att ha tagits bort och reparerats Ater installeras i systemet, skall systemet Aterga till den initiala konfigurationen. Detta kan ske antingen genom att cloth alla mjukvaruobjekt i den aktuella konfigurationen och genom att skapa och starta alla mjukvaruobjekt pA processorerna i systemet. I den foreslagna utforingsformen av uppfinningen cloths forst endast de objekt som flyttats bort frAn den forsta processorn och som nu exekverar pA andra processorer. Darefter Aterskapas och startas dessa pA processorn Pl. For att hitta dessa objekt skapas en deltakonfigurationstabell genom att sub- • ." •trahera den initiala konfigurationen frAn den aktuella konfi- ." gurationen med uteslutande av processorn Pl. Genom att subtra- •• • •• ••• • • • • . 12 ••• ••• ••.: : : 7 .••."': ••• .• : .••..•'. •••••••• :•••.. • :•• •• •• hera Tabell 1 frAn Tabell 6 erhAlls den i Fig. 7 visade deltakonfigurationen. Den rad som avser den trasiga processorn- P1 ingAr inte i subtraktionen. Deltakonfigurationen visar att objekten 1 och 3 pA processorn P2 och att objektet P2 pA pro- 5 cessorns P4 skall cloths pA de respektive processorerna. Darefter skall de Aterskapas och startas p& den reparerade processorn Pl. Nar objekten Aterskapats kommer systemet att kora pA samma satt som det gjorde i den initiala konfigurationen och systemets Aterhamtiningstid blir kort. 10 Processor P1 havererar och dar efter havererar processor P2. I det foljande exemplet antas att processorn P1 gar sonder och darefter att processorn P2 gAr sonder. Med anknytning till det fOregAende exemplet antas forst att systemet är i drift med 15 samma konfiguration som i Fig. 1, att katastrofplaner har skapats for var och en av processorerna P1-P4, att processorn P1 havererar, att mjukvaruobjekten pa processorn P1 flyttas Over till de driftsdugliga processorerna i enlighet med katastrofplanen i Tabell 2, att systemet Aterhamtar sig och är i drift, 20 att nya katastrofplaner skapas for processorerna P2, P3-och P4, att processorn P1 tas bort och lamnas till reparation. Nu antas att processorn P2 havererar. SAledes skall den nya katastrofplanen som her ihop med processorn P2, d v s den nya katastrofplanen i Tabell 8, foljas. Enligt denna katastrofplan 25 skall objekten 1, 3 och 4 flyttas till processorn P3 och objek••• • •• • ten 5-7 skall flyttas till processorn P4. Pa samma satt som • • ▪ •tidigare tas mjukvaruobjekten pa processorn 2 bort och flyttas •• • • •Over till processorerna P3 och P4. Systemet kommer nu att vara •• • • • I funktion och kora med den konfiguration som visas i Fig. 3 " . och Tabell 11. I enlighet med uppfinningen är det nu nodvandigt • " • •att utarbeta nya katastrofplaner for var och en av processorer- na P3 och P4. ••• • • • • 13 • Of • .60 : • • • • • 000• : • • • • •••••••• • • • • • • ■•• • 000 ••• Under perioden frAn processorns P2 haven i till det att nya ka- tastrofplaner for processorerna P3 och P4 har utarbetats och lagrats i systemet kommer systemet vara sArbart. Om sAledes en- 5 dera P3 eller P4 havererar kommer systemet att vara otillgdngligt. Nu antas att detta inte intrdffar. Istdllet an systemet i drift med den konfiguration som visas i Fig. 3 och Tabell 11. • • ••. • • • • • • • In the same way as the original disaster plans, the • - •: ° 310 new disaster plans and their mirror copies are stored in the way described above. ••• •••••: •••••••• • •••••••• •••••••• ••• • •• • • • •• •• • •• • •• •• ••• • • • •• • •• •• •• • • • ••• • • 11 • •• • •• •• •••• •• It should be noted that the preparation of new disaster plans for the current configuration saves memory compared to the following theoretical concept conceivable scheme: assume that the system consists of four processors and that the system is designed so that it tolerates that two processors are probes. Since it is not possible to predict which processor goes probes first and which processor goes probes as number two, one must create as many disaster plans as the number of different ones depending on which two elements can be selected from a group of four elements. These 10 mAste disaster plans are stored in the database. Thus, twenty-four disaster plans must be created and stored. This storage requires a lot of memory space. The memory space grows faster than exponentially with the number of processors the system can tolerate. 15 During the period from the time the Aterhamt system progressed until new contingency plans were prepared and stored in the database, the system was vulnerable. During this period, no processors gA sander. Should a processor fail during this period, the system will not be available. .2 • •• •: • When a PI processor is removed from the system after it has been removed and repaired, the system must return to the initial configuration. This can be done either by cloth all the software objects in the current configuration and by creating and starting all the software objects on the processors in the system. In the proposed embodiment of the invention, only the objects which have been moved away from the first processor and which now execute on other processors are first clothed. Then these are recreated and started on the processor Pl. To find these objects, a delta configuration table is created by subtracting the initial configuration from the current configuration. guration with the exclusion of the processor Pl. By subtracting •• • •• ••• • • • •. 12 ••• ••• •• .::: 7. ••. "': •••. •:. •• .. •'. •••••••••: ••• .. • Table 1 from Table 6 is obtained from the delta configuration shown in Fig. 7. The row relating to the broken processor P1 is not included in the subtraction, the delta configuration shows that objects 1 and 3 on processor P2 and that object P2 The processor P4 must be clothed on the respective processors, then they must be recreated and started on the repaired processor P1. When the objects are recreated, the system will run in the same way as it did in the initial configuration and the system retrieval time will be short. In the following example, it is assumed that the processor P1 is probing and then that the processor P2 is probing. In connection with the previous example, it is first assumed that the system is in operation with the same configuration as in Fig. 1. that disaster plans have been created for each of the processors P1-P4, that the processor P1 fails, that the remaining objects on the processor P1 are moved to the operational processors in accordance with the disaster plan in Table 2, that the system recovers and is in operation, that new disaster plans are created for the processors P2, P3 and P4, that the processor P1 is removed and left for repair. . It is now assumed that the processor P2 fails. Thus, the new disaster plan, which here together with the processor P2, i.e. the new disaster plan in Table 8, must be followed. According to this disaster plan 25, objects 1, 3 and 4 must be moved to processor P3 and objects 5-7 must be moved to processor P4. In the same way as • • ▪ • previously, the software objects on processor 2 are removed and moved •• • • • Over to processors P3 and P4. The system will now be •• • • • In operation and run with the configuration shown in Fig. 3 ". And Table 11. In accordance with the invention it is now necessary •" • • to prepare new emergency plans for each of processors P3 and P4. ••• • • • • 13 • Of • .60: • • • • • 000 •: • • • • •••••••• • • • • • • • •• • 000 ••• During the period from the processor P2 in until new disaster plans for the processors P3 and P4 have been prepared and stored in the system, the system will be vulnerable. Thus, if either P3 or P4 fails, the system will be inaccessible. Now it is assumed that this does not occur. Istdllet the system in operation with the configuration shown in Fig. 3 and Table 11.

Nu tas processorn P2 bort frAn systemet och ldmnas till repara- 10 tion. Darefter antas att processorerna P1 och P2 blir reparerade och att de sdtts tillbaka in i systemet. Det kommer nu att bli nodvdndigt att dada objekten 1-7 och processorerna P3 och P4 och att Aterskapa och starta dem pA sina respektive usprungliga processorer P1 och P2. Genom att anvanda en deltakon- 15 figuration, som erhAlls genom att subtrahera den initiala konfigurationen frAn den aktuella konfigurationen i Fig. 1, med undantagande av de trasiga processorerna P1 och P2 denna gang, kommer de objekt som mAste cloths identifieras; ± detta fall 17. Narmare bestamt skall objekten 1, 3, 4 pA processor P3 och 20 objekten 2, 5, 6, 7 pA processorn P4 flyttas Over. Det satt pa vilket dessa objekt skall distribueras pA processorerna P1 och P2 ges av den initiala konfigurationstabellen. SAledes skapas och startas objekten 1, 2, 3 pA processorn P1 och objekten 4-7 skapas och startas pA processorn P2. Systemet har nu Aterhdmtat 25 sig frAn inkopplingen av de tvA reparerade processorerna och • . • • " •antas nu vara i drift. Now the processor P2 is removed from the system and left for repair. It is then assumed that the processors P1 and P2 are repaired and that they are put back into the system. It will now be necessary to kill objects 1-7 and processors P3 and P4 and to recreate and start them on their respective original processors P1 and P2. Using a delta configuration obtained by subtracting the initial configuration from the current configuration in Fig. 1, with the exception of the broken processors P1 and P2 this time, the objects that must be clothed will be identified; ± this case 17. More specifically, objects 1, 3, 4 pA processor P3 and objects 2, 5, 6, 7 pA processor P4 must be moved Over. The way in which these objects are to be distributed on the processors P1 and P2 is given by the initial configuration table. Thus, objects 1, 2, 3 are created and started on processor P1 and objects 4-7 are created and started on processor P2. The system has now recovered from the connection of the two repaired processors and •. • • "• is now assumed to be in operation.

• • • • •• • •• • • • • • I de ovanstAende exemplen har ett processorsystem med fyra pro- cessorer beskrivits. Uppfinningen An lika val tillampbar pA • :%39 processor system som innehAller tvA, tre, fern eller flera pro- • ••• • • ••• •• • •• • ••• • • • • • cessorer. I det sista exemplet beskrevs ett processor system som tolererade tvA processorhaverier. Uppf innings forfarandet •• .*:.".. : 7..• :•••••••• •:•• ••• är lika val tillampbart pa processorsystem som tolererar tre eller flera processorhaverier. Varje gang -en processor havererar flyttas dess mjukvaruobjekt till andra funktionsdugliga processorer i systemet och nya katastrofplaner for de funk- 5 tionsdugliga processorerna skapas. Det sista exemplet illustrerar att ett av fyra processorer bestaende processorsystem kan vara i drift med 50% av processorerna havererade. Applikationen kommer fortfarande att exekvera ehuru med ett nedsatt kapacitet. Om processorsystemet är en valjare i en telefonstation 10 kommer telefontrafiken fortfarande att vara i gang och sparr kommer att intraffa vid lag trafikvolym. Detta är ett nytt och unikt sardrag som inte finns i flagon av de ovan namnda amerikanska patenten och, savitt sokanden är bekant, har ingen tidigare kunnat astadkomma detta. • • • • •• • •• • • • • • In the above examples, a processor system with four processors has been described. The invention An equal choice applicable to •:% 39 processor systems containing TWO, THREE, FOUR or MORE PRO- • ••• • • ••• •• • •• • ••• • • • • • processors. The last example described a processor system that tolerated two processor failures. Invention Procedure ••. * :. "..: 7 .. •: •••••••• •: •• ••• is equally applicable to processor systems that tolerate three or more processor failures. Each time -en processor fails, its software objects are moved to other working processors in the system and new disaster plans for the working processors are created.The last example illustrates that a processor consisting of four processors can be in operation with 50% of the processors failing.The application will still execute Although with a reduced capacity.If the processor system is a selector in a telephone exchange 10, the telephone traffic will still be running and the spar will occur at low traffic volume.This is a new and unique feature not found in the flag of the above mentioned US patents and , as far as the applicant is aware, no one has been able to achieve this before.

En fOrsta algoritm anvands till att skapa katastrofplaner fran den initiala konfigurationen i det fall att en forsta processor havererar eller fran den aktuella konfigurationen i det fall att en tillkommande processor havererar. Den forsta algoritmen 20 innehaller parametrar som avser kapaciteten for en processor, parametrar som avser storleken av minnet av en processor, parametrar som avser hur mycket processorkapacitet (maskincykler per process som skall exekvera) och minne de enskilda flyttade objekten erfordrar, samt parametrar avseende tjanstens kvalite. A first algorithm is used to create disaster plans from the initial configuration in the event that a first processor fails or from the current configuration in the event that an additional processor fails. The first algorithm 20 contains parameters relating to the capacity of a processor, parameters relating to the size of the memory of a processor, parameters relating to how much processor capacity (machine cycles per process to execute) and memory the individual moved objects require, as well as parameters regarding the quality of service .

• • •• • • • • • En andra algoritm anvands for att aterfOra systemet till dess initiala konfiguration. Denna andra algoritm har redan beskrivits ovan och kallades for deltakonfiguration. • • • •• • •• • • • • • •• " • :•50 Olika metoder kan anvandas for att detektera en trasig proces- • ••• • • ••• •• • •• ••• • • • • sor, t ex "hjartslagsmetoden" i enlighet med den ovan namnda amerikanska patentskriften 4 710 926. En foredragen metod i ett 14 • ..•.°:.".. ::•••••••• •:•• ••• typiskt telekomnat är emellertid att overvaka de lankar som kopplar ihop processorerna med varandra i natet Ni. I samband med de tva ovan beskrivna exemplen beskrevs att mjukvaruobjekt som fanns installerade pa en havererad processor overflyttades 5 till tva processorer. Naturligtvis kan den havererade processorns objekt aven distribueras pa tre eller flera processorer i systemet. I undantagsfall kan samtliga mjukvaruobjekt flyttas Over till en enda processor i det fall att systemet bestar av tva driftsdugliga processorer och den ena av dessa havererar. • • •• • • • • • A second algorithm is used to return the system to its initial configuration. This second algorithm has already been described above and was called delta configuration. • • • • • • •• • • • • • •• "•: • 50 Different methods can be used to detect a broken process- • ••• • • ••• •• • •• ••• • • • • sor, for example, the "heartbeat method" in accordance with the aforementioned U.S. Patent 4,710,926. A preferred method in a 14 • .. •. ° :. ".. :: •••••••• •: •• ••• typical telecomnet, however, is to monitor the lines that connect the processors to each other in the network Ni. In connection with the two examples described above, it was described that software objects that were installed on a failed processor were transferred to two processors. Of course, the objects of the failed processor can also be distributed on three or more processors in the system. In exceptional cases, all software objects can be moved Over to a single processor in the event that the system consists of two operational processors and one of these fails.

Nar systemet är i drift är alla processorerna är driftsdugliga och har mer kapacitet och mer minne an vad som erfordras for att de skall utfOra sina jobb med beraknad kapacitet, d v s de skall ha kapacitet och minne Over for att ta over objekt fran 15 en eller flera processorer och for att ta Over applikationsjobb som är under exekvering. Pa sá satt sakerstalls att samtliga processorer är driftsdugliga och inget testprogram behover koras for att verifiera detta. Vidare kommer systemets kapacitet att overskrida den beraknade kapaciteten, vilket betyder att 20 systemet kommer att ha "reservkapacitet" som kan anvandas for att ta hand om ytterligare applikationsjobb; det finns ingen clod "reserv"-kapacitet. FOr applikationen kommer en havererad processor endast medfora att systemet kapacitet nedsatts; have-net kommer inte att cloth systemet. When the system is in operation, all the processors are operational and have more capacity and more memory than what is required for them to perform their jobs with calculated capacity, ie they must have capacity and memory Over to take over objects from one or more processors and to take over application jobs that are being executed. This ensures that all processors are operational and no test program needs to be run to verify this. Furthermore, the capacity of the system will exceed the calculated capacity, which means that the system will have "spare capacity" that can be used to take care of additional application jobs; there is no clod "reserve" capacity. For the application, a failed processor will only cause the system capacity to be reduced; have-net will not cloth the system.

• . •• . Sasom ett alternativ till att dimensionera systemet med en ak- ••• • • •tiv "reserv"-kapacitet som kan anvandas for att ta hand om •• . •••tillkommande applikationsjobb, kan systemet designas med ingen • . • • •aktiv "reserv"-kapacitet och med samtliga processorer arbetande med dimensionerad kapacitet. Nar en processor havererar kommer . . ••• • • ••• •• • •• • ••• • • • • systemet att arbeta med nedsatt kapacitet. 16 ••• ••• ••••• • •• • • •• •• •• • :•••••••:. •. ••. As an alternative to dimensioning the system with an active "reserve" capacity that can be used to take care of ••. ••• additional application jobs, the system can be designed with no •. • • • active "reserve" capacity and with all processors working with dimensioned capacity. When a processor crashes. . ••• • • ••• •• • •• • ••• • • • • the system to work with reduced capacity. 16 ••• ••• ••••• • •• • • •• •• •• •: ••••••• :.

• ••• • •• • • • • • •• • •• •••••••• •• •• •• •• •• • •••••••• •• • • •••• • ••• • •• Fig. 4 ar ett flodesschema som visar de metodsteg som utfOrs i enlighet med uppfinningen. Det finns alltid en initial konfiguration i vilken samtliga modulariserade Mjukvaruobjekt är mappade pa enskilda processorer. Den initiala konfigurationen 5 skapas av systemsaljaren eller systemoperatoren och lagras i systemet. Detta anges i ruta 20. Darefter skall katastrofplaner skapas ± enlighet med den forsta algoritmen. Det skall finnas lika manga katastrofplaner som processorer i systemet. Vidare skall spegelkopior av persistenta databasobjekt skapas. Detta 10 anges i ruta 21. I en foredragen utfOringsform skapar vane processor sin egen katastrofplan, d v s den katastrofplan som systemet skall anvanda i handelse av processorn havererar. At-garden sakerstaller att arbetet med att skapa katastrofplanerna blir fullstandigt distribuerat. Darefter havererar en proces- 15 sor, ruta 22. Mjukvaruobjekten pa den havererade processorn skall flyttas over till driftsdugliga processorer med utnyttjande av katastrofplanen for den havererade processorn. Med uttrycket "flytta Over" objekt avses att nya kopior av mjukvaruobjekten pa den havererade processorn skapas och startas pa 20 de processorer till vilka de skall flyttas Over i enlighet med katastrofplanen. Detta anges i ruta 23. Ruta 23 representerar saledes systemets Aterhamtning frail den havererade processorn. Systemet är nu i drift och en ny konfiguration, benamnd den aktuella konfigurationen, uppstar. Den aktuella konfigurationen 25 lagras ocksa i ett minne av en distribuerad processor. Medan • • • •• •systemet är i drift skapas nya katastrofplaner for de funk- . • •tionsdugliga processorerna, ruta 24. Nu har systemet atervunnit • • • . - •sin formaga att motsta ett nytt processorhaveri. Aven spegelko- • . • • .• . • pior av de ny katastrofplanerna lagras i databasen. Om en ny • F..30 processor havererar sker atergang till operation 22, visat av • • •pilen 25. Darefter repareras den eller de havererade processo- -- • ••rerna ruta 26, och satts tillbaka i systemet, ruta 26. Om tva ••• • • • • •• • • •• •••• •• •••• •• • • • •• • • • • • • • • • •• ••• • ••• • • •• • •••• •• • • • • ••••• ••• •• • • ••• ••• ••• •• •••• •• eller flera processorer har havererat antas att de repareras och sdtts tillbaka i systemet samtidigt. Teoretiskt sett är det naturligtvis mojligt att reparera havererade processorer en och en At gAngen och att de sdtts tillbaka i systemet en och en At 5 gAngen. Ur praktisk synpunkt är detta emellertid en omvdg. Det sista steget i processen, ruta 27, är att ta tillbaka systemet till dess initiala konfiguration med anvdndande av den andra algoritmen. 10 I de ovan beskrivna exemplen har antagits att mjukvaruobjekten 1-18 inte styr nAgon hArdvaruutrustning. Exempel pA hArdvaruutrustning som styrs av mjukvarumoduler är I/O-anordningar, grdnssnitt mot abonnentlinje, processorer mot abonnentlinjer, tonavkodare, talbeskedsutrustningar, konferensutrustning. Hard- 15 varuberoenden av detta slag skapar restriktioner pA mjukvarumodulerna. En mjukvarumodul som är involverad i styrning av en hArdvaruutrustning som är ansluten till en eller flera processorer kan inte flyttas over till en godtycklig processor i systemet utan maste flyttas Over till en processor som har access 20 till denna hArdvaruutrustning. Katastrofplaner mAste skapas med detta i Atanke. • ••• • •• • • • • • •• • •• •••••••• •• •• •• •• •• • •••••••••• • • • •• •• • ••• • •• Fig. 4 is a flow chart showing the method steps performed in accordance with the invention. There is always an initial configuration in which all modularized Software objects are mapped on individual processors. The initial configuration is created by the system vendor or system operator and stored in the system. This is indicated in box 20. Next, disaster plans must be created ± according to the first algorithm. There must be as many disaster plans as processors in the system. Furthermore, mirror copies of persistent database objects must be created. This is indicated in box 21. In a preferred embodiment, the habitual processor creates its own disaster plan, i.e. the disaster plan that the system is to use in the event of the processor failing. At-garden ensures that the work of creating the disaster plans is fully distributed. Then a processor crashes, box 22. The software objects on the crashed processor must be moved to operational processors using the disaster plan for the crashed processor. The term "move Over" object means that new copies of the software objects on the failed processor are created and started on the processors to which they are to be moved Over in accordance with the disaster plan. This is indicated in box 23. Box 23 thus represents the system's recovery from the failed processor. The system is now operational and a new configuration, called the current configuration, is emerging. The current configuration is also stored in a memory by a distributed processor. While the • • • •• • system is in operation, new disaster plans are being created for the functional. • • capable processors, box 24. Now the system has recovered • • •. - • its ability to withstand a new processor failure. Aven spegelko- •. • •. •. • piors of the new disaster plans are stored in the database. If a new F..30 processor fails, it returns to operation 22, indicated by the arrow • • • • The failed processor (s) box 26 is then repaired, and put back in the system, box 26. About two ••• • • • • •• • • •• •••• •• •••• •• • • • • • • • • • • • • • • • • •• • ••• • • •• • •••• •• • • • • ••••• ••• •• • • ••• ••• ••• •• •••• •• or several processors have failed is assumed that they are repaired and sdtts back into the system at the same time. Theoretically, it is of course possible to repair failed processors one at a time and that they are put back into the system one at a time. From a practical point of view, however, this is a reversal. The final step in the process, box 27, is to return the system to its initial configuration using the second algorithm. In the examples described above, it has been assumed that software objects 1-18 do not control any hardware equipment. Examples of hardware equipment controlled by software modules are I / O devices, interfaces to the subscriber line, processors to the subscriber lines, tone decoders, voice messaging equipment, conference equipment. Hardware dependencies of this kind create restrictions on the software modules. A software module involved in controlling a hardware equipment connected to one or more processors cannot be transferred to any processor in the system but must be transferred to a processor having access to this hardware equipment. Disaster plans must be created with this in Atanke.

Ett telekomsystem kan vanligen fortsdtta sin drift trots for-lust av vissa organ men de tjdnster telekomsystemet tillhanda25 hAller kan hdmmas. • 17 • • •• • • • • • • • •• • • • • • Till den grad det är mojligt mAste sAledes en katastrofplan allokera organstyrande mjukvaruobjekt till processorer som har access till de styrda organen. Om detta inte är mOjligt mAste F-10 de modulariserade mjukvaruobjekten som styr organen uteslutas • ur katastrofplanen. Ett uteslutet mjukvaruobjekt är alltid av den typ som visas i Fig. 6C. A telecom system can usually continue to operate despite loss of certain means, but the services provided by the telecom system can be hampered. • 17 • • •• • • • • • • • •• • • • • • To the extent possible, a disaster plan must thus allocate organ-controlling software objects to processors that have access to the controlled organs. If this is not possible, the F-10 modularized software objects that control the devices must be excluded from the disaster plan. An excluded software object is always of the type shown in Fig. 6C.

•• • • ••• •• • • •• •••• •• •••• •• • •• •• • • • • • • • • • •• ••• • ••• • • ••• •••• •• • • • • ••••• :• •• • • •• •• ••• •• •••• •• Fig. 6B illustrerar ett mjukvaruobjekt som innehAller en funktionsdel (exekveringsdel) och en del med persistent data (persistentdata-del). Mjukvaruobjektet i Fig. 6C innehAller 5 funktionsdelen av mjukvaruobjektet i Fig. 6B och mjukvaruobjek- tet i Fig. 6D innehAller persistentdata-delen av samma mjukvaruobjekt som visas i Fig. 6B. Mjukvaruobjekten i Fig. 6C och 6D bildar tillsammans ett par och de har samma nyckel. Nyckeln ax det i Fig. 6B visade mjukvaruobjektets logiska adress till 10 databasen och nyckeln kommer darfor aven att vara den logiska adressen till de tvA mjukvaruobjekten i Fig. 6C och 6D i databasen. Det är mjukvaruobjektet i Fig. 6C som styr en anordning. Det dr i detta mjukvaruobjekt som det finns ett hArdvaruberoende. •• • • ••• •• • • •• •••• •• •••• •• • •• •• • • • • • • • • •• ••• • ••• • • ••• •••• •• • • • • •••••: • •• • • •• •• ••• •• •••• •• Fig. 6B illustrates a software object that containsA function part ( execution part) and a part with persistent data (persistent data part). The software object in Fig. 6C contains the functional part of the software object in Fig. 6B and the software object in Fig. 6D contains the persistent data part of the same software object as shown in Fig. 6B. The software objects in Figs. 6C and 6D together form a pair and they have the same key. The key is the logical address of the software object shown in Fig. 6B to the database and the key will therefore also be the logical address of the two software objects in Figs. 6C and 6D in the database. It is the software object in Fig. 6C that controls a device. It is in this software object that there is a hardware dependency.

Ett exkluderat mjukvaruobjekt i en aktuell konfiguration mAste blockeras, d v s andra mjukvaruobjekt skall inte kunna kommunicera med det. I en foredragen utforingsform Astadkoms blockering genom att satta persistentdata-delen av mjukvaruobjektet i 20 Fig. 6D i blockerat tillstand. Ett blockerat tillstand markeras genom att stalla en flagga i mjukvaruobjektet. Det bor observeras att det inte är det organstyrande mjukvaruobjektet 6C som blockeras utan dess persistenta tvilling-mjukvaruobjekt i Fig. 6D. Genom att undersoka tillstAndet av ett mjukvaruobjekt innan 25 applikationen borjar kommunicera med mjukvaruobjektet kan ap- • • • " •plikationen hantera blockerade organ RA ett ordnat satt. • • • 18 • • • •• •• • • • •nsom ett alternativ till att blockera mjukvaruobjekt med s • •stand flagga i databasrepresentationen av mjukvaruobjektet kan r.8.0 mjukvaruobjektet blockeras i de adresstabeller som finns i de • •• ••• to • ••• •• • •• •• • • • • respektive processorernas operativsystem. Operativsystemet av en processor har en adresstabell till sina egna mjukvaruobjekt. 19 • .0 9 SOO :: t •• O. • 0.0 00. • • : 000:...I. • • 9 • • e .4.. An excluded software object in a current configuration must be blocked, ie other software objects must not be able to communicate with it. In a preferred embodiment, blocking is accomplished by setting the persistent data portion of the software object in Fig. 6D to the blocked state. A blocked state is marked by placing a flag in the software object. It should be noted that it is not the organ control software object 6C that is blocked but its persistent twin software object in Fig. 6D. By examining the condition of a software object before the application starts communicating with the software object, the application can handle blocked means RA in an orderly manner. • • • 18 • • • • • • • • • • • n as an alternative to to block software objects with s • • stand flag in the database representation of the software object, r.8.0 the software object can be blocked in the address tables contained in the • •• ••• to • ••• •• • •• •• • • • • and the processors' operating system.The operating system of a processor has an address table for its own software objects.19 • .0 9 SOO :: t •• O. • 0.0 00. • •: 000: ... I. • • 9 • • e .4. .

•• • • • • • • ID 0 .0.. • 00. •• • • • • • • ID 0 .0 .. • 00.

Adresstabellerna anvands nar meddelanden skickas till operativsystemets mjukvaruobjekt. The address tables are used when messages are sent to the operating system software objects.

I begreppet kvalite av en tjanst inkluderas det faktum att pro- 5 cessorerna i ett processorsystem kan vara av tva slag, feltoleranta processorer (FTP-processorer) och icke-FTP-processorer. En FTP processor, som vanligen innefattar dubbla processorer, fortsatter att exekvera sina jobb aven om det uppstar ett enkelt hardvarufel i den hardvara som FTP-processorn styr. Nar 10 felet uppstAr triggas ett alarm men programmet havererar inte. Med hjalp av organ, vilka inte beskrivs i foreliggande uppfinning eftersom de inte bildar flagon del av denna uppfinning, är det mOjligt att ta en FTP-processor ur tjanst, sá att de kan repareras, pA ett kontrollerat satt med anvandande av katastro- 15 fplanerna. De tjanster applikationen tillhandahaller kommer inte att avbrytas. SAsom ett exempel kan namnas att i ett telekomsystem kommer inga trafikstorningar att intraffa; pagaende koppel ej att brytas. SystemAterhamtning till foljd av borttagning av en FTP-processor kommer saledes inte att bryta levere- 20 rade tjanster. Genom att kombinera den fOreliggande uppfinningen med de ovan beskrivna FTP-processorerna, är det mojligt att Astadkomma mycket hog systemtillganglighet samt mycket hog tjanstetillforlitlighet nar hardvarufel intraffar. Kort sammanfattat är syftet med parametern tjanstekvalite att stOdja FTP- 25 processorer fOr programvara som kraver mycket hog tjanstetill- . • • . .forlitlighet. En FTP-processor kommer saledes att maskera ett •• internt hardvarufel men FTP-processorn maste repareras innan • • • • nya interna hardvarufel uppstar. • r.e.0 I Fig. 5 visas ett processor system likartat det i Fig. 1, var- • vid det forekommer ett nat Ni till vilket processorer P1-P4 har access och kan kommunicera med varandra. Ehuru ej visat i Fig. •• •• •• • • • • •• • • • • • • • 0 • • •• • • ••_ ••• •••• •••: .41% •••• •• • • •• • •• • ••• : • • • ••• ..• • • : • • •••• • • •• • •••• • • • :•• • ••• ••• 5 antas att mjukvaruobjekten 1-18 är distribuerade pa processoxerna P1-P4 pa samma satt som visas i Fig. 1. Vidare visas ett organ D1 vara ansluten till processorn Pl. Det finns ocksa ett andra nat N2 till vilket processorer P2 och P4 har access. En 5 organprocessor D6 är en anordning som anvands for att ansluta organ D2 och D3 till natet N2. Organprocessorn D6 styr saledes anordningarna D2 och D3. En annan organprocessor D7 ansluter anordningar D4 och D5 till natet N2 och styr saledes dessa. Det finns mjukvaruobjekt som ansluter anordningarna Dl, D2, D3 ... 10 D7 till processorsystemet. Sasom ett exempel antas mjukvaruob- jektet 1 styra organet Dl. Om P1 havererar kan ingen av processorerna P2-P4 styra organet Dl. Saledes kan objektet 1 inte flyttas Over till nagon av processorerna P2-P4. Vad betraffar organen D2-D7 galler emellertid att mjukvaruobjekt som 15 styr nagot eller nagra av dessa organ maste vara installerade pa en processor som kan kommunicera med dessa organ. Organen D2-D5 kan styras via natet N2 och saledes kan mjukvaruobjekt som styr nagot eller nagra av dessa organ installeras pa nagon av processorerna P2 och P4. Processorerna P1 och P3 kan daremot 20 inte komma i fraga. Sammanfattningsvis galler saledes att ett mjukvaruobjekt som ansluter hardvara till systemet maste installeras pa en processor som har access till denna hardvara. The concept of quality of service includes the fact that the processors in a processor system can be of two types, fault-tolerant processors (FTP processors) and non-FTP processors. An FTP processor, which usually includes dual processors, continues to execute its jobs even if a simple hardware failure occurs in the hardware controlled by the FTP processor. When the error occurs, an alarm is triggered but the program does not crash. By means of means which are not described in the present invention because they do not form a flawed part of this invention, it is possible to take an FTP processor out of service, so that they can be repaired, in a controlled manner using the disaster plans. . The services provided by the application will not be interrupted. As an example, it can be mentioned that in a telecom system no traffic disruptions will occur; pagende leash not to be broken. Thus, system recovery following the removal of an FTP processor will not disrupt delivered services. By combining the present invention with the FTP processors described above, it is possible to achieve very high system availability as well as very high service reliability when hardware errors occur. In short, the purpose of the service quality parameter is to support FTP processors for software that requires very high service performance. • •. .reliability. An FTP processor will thus mask an internal hardware failure, but the FTP processor must be repaired before new internal hardware failures occur. • r.e.0 Fig. 5 shows a processor system similar to that in Fig. 1, whereby • there is a nat Ni to which processors P1-P4 have access and can communicate with each other. Although not shown in Fig. •• •• •• • • • • • • • • • • • • • • • • • • • • • • _ ••• •••• •••: .41% • ••• •• • • •• • •• • •••: • • • ••• .. • • •: • • •••• • • •• • •••• • • • • •• • ••• ••• 5 it is assumed that the software objects 1-18 are distributed on the process oxen P1-P4 in the same way as shown in Fig. 1. Furthermore, a means D1 is shown to be connected to the processor P1. There is also a second nat N2 to which processors P2 and P4 have access. A means processor D6 is a device used to connect means D2 and D3 to the network N2. The organ processor D6 thus controls the devices D2 and D3. Another means processor D7 connects devices D4 and D5 to the network N2 and thus controls them. There are software objects that connect the devices D1, D2, D3 ... 10 D7 to the processor system. As an example, the software object 1 is assumed to control the means D1. If P1 fails, none of the processors P2-P4 can control the means D1. Thus, the object 1 cannot be moved Over to any of the processors P2-P4. However, as far as means D2-D7 are concerned, software objects controlling some or some of these means must be installed on a processor capable of communicating with these means. The means D2-D5 can be controlled via the network N2 and thus software objects which control some or some of these means can be installed on any of the processors P2 and P4. Processors P1 and P3, on the other hand, cannot be considered. In summary, a software object that connects hardware to the system must be installed on a processor that has access to this hardware.

Typiska exempel pa ett organ av slaget D1 är processorn P1 25 sjalv. Ett annat exempel är en hardvaruanordning, t ex en UART- • • • •• • anordning. Om processorn PI havererar eller cm den hardvaruanordning som processorn P1 styr havererar kan inte det mjukvaruobjekt som representerar processorn P1 eller ett mjukvaruobjekt som representerar den havererade hardvaran flyttas • • • • • • • •• • •• • • • • • • • . 00 Over till nagon av processorerna P2-P4 eftersom de sistnamnda ••• .. - • 4041 • • .094t •processorn Pl. Likval maste processorsystemet tolerera att PI " ••• • • • • • inte kan fá kontroll over den havererade hardvaran eller Over 21 ••• • •• ••••• • •• : •• •• •••••••: • ••• ••• • • : • •• •••• •••••••• •• •• :• .••••••• •• •••• • ••1: •• havererar om systemet skall vara redundant. Om det mjukvaruobjekt som representerar processorn P1 havererar maste det mjukvaruobjekt som representerar processorn P1 blockeras och att det inte kan accessas av nagot annat mjukvaruobjekt. Typical examples of a device of the type D1 are the processor P1 itself. Another example is a hardware device, such as a UART device. If the processor PI fails or cm the hardware device that the processor P1 controls fails, the software object representing the processor P1 or a software object representing the failed hardware cannot be moved • • • • • • • • • • • • • • • •. 00 Over to any of the processors P2-P4 because the latter ••• .. - • 4041 • • .094t • the processor Pl. However, the processor system must tolerate that the PI "••• • • • • • can not gain control over the damaged hardware or Over 21 ••• • •• ••••• • ••: •• •• ••••• ••: • ••• ••• • •: • •• •••• •••••••• •• ••: •. ••••••• •• •••• • • • 1: •• fails if the system is to be redundant If the software object representing processor P1 fails, the software object representing processor P1 must be blocked and cannot be accessed by any other software object.

Betrakta Fig. 1. Varje processor Pl-P4 har varsitt objekt som beskriver processorn. Narmare bestamt representerar objekt 1 processorn P1, objekt 4 processorn P2, objekt 8 processorn P3 och objekt 13 processorn P4. Alla dessa hardvaruberoenden be- 10 skrivs exakt av den hardvarumodell pa vilken mjukvarumodellen i Fig. 7 är installerad. Saledes visar modellen att inget av dessa objekt 1, 4, 8 och 13 kan flyttas Over till flagon annan processor i systemet. Den fOrsta algoritmen arbetar pa hardvarumodellen med installerad mjukvara och kommer saledes att ta 15 hansyn till alla hardvaruberoenden nar den skapar nya katastrofplaner. Processorns 1 katastrofplan, visad i Tabell 1, kommer darfor att forbli densamma med undantag for att objektet 1 forsvinner. I katastrofplanen for processor 2 (Tabell 3) kommer objektet 4 att forsvinna och katastrofplanen for processorn 3 20 kommer objektet 8 att forsvinna. I katastrofplanen for processorn P4 kommer objektet 13 att forsvinna. Ett farre antal objekt an vad som beskrivits tidigare kommer saledes att finnas kvar pa de respektive processorerna nar en processor havererar. 25 Om t ex processorn P1 havererar maste objektet 1 blockeras mot • • •• • • access fran andra mjukvaruobjekt. Detta betyder att inga andra mjukvaruobjekt tillats kommunicera med mjukvaruobjektet 1. Consider Fig. 1. Each processor P1-P4 has its own object that describes the processor. More specifically, object 1 represents processor P1, object 4 processor P2, object 8 processor P3 and object 13 processor P4. All of these hardware dependencies are described exactly by the hardware model on which the software model of Fig. 7 is installed. Thus, the model shows that none of these objects 1, 4, 8 and 13 can be moved Over to the other processor in the system. The first algorithm works on the hardware model with installed software and will thus take into account all hardware dependencies when it creates new disaster plans. The processor 1's disaster plan, shown in Table 1, will therefore remain the same except that object 1 disappears. In the disaster plan for processor 2 (Table 3) the object 4 will disappear and the disaster plan for the processor 3 20 the object 8 will disappear. In the disaster plan for the processor P4, the object 13 will disappear. A smaller number of objects than what has been described previously will thus remain on the respective processors when a processor fails. If, for example, the processor P1 breaks down, the object 1 must be blocked from accessing other software objects. This means that no other software objects are allowed to communicate with the software object 1.

Modellen enligt uppfinningen kommer alltid att latsas att sys- • • • •• • •• • • • • • temet ar i drift aven om hardvaruutrustning gar sonder och inte • ." • •kan kontrolleras av sitt eller sina mjukvaruobjekt. Om emeller- ". tid det pa den hogre niva i systemet visar sig att systemet 22 ••• • •• • •• •• •• :.••.'"•: • ••• ..• • • • • •••••••• •• • • •• • • • • ■•■•• •• • • ••• ••• inte är i drift, inte ens kan leverera tjdnster med nedsatt kvalite, dá är orsaken till detta att finna i bristande redundans och modellen kan inte dndra pa detta faktum. 5 I Fig. EA visas mjukvarumodellen av det modulariserade mjukvaruobjektet. Mjukvarumodellen bestar av en klass bendmnd configObj som har operationerna construct() och destruct(). Construct() och destruct() anvdnds for att skapa respektive doda ett enskilt moduldrt mjukvaruobjekt. Det moduldra mjuk- 10 varuobjektet har beskrivits ovan i samband med Fig. 6B-6D. The model according to the invention will always be left to the system • • • •• • •• • • • • • the system is in operation even if hardware equipment is probing and not •. "• • can be controlled by his or her software objects. ". time it at the higher level of the system turns out that the system 22 ••• • •• • •• •• ••:. ••. '"•: • ••• .. • • • • • •••• •••• •• • • •• • • • • ■ • ■ •• •• • • ••• ••• is not in operation, can not even deliver services with reduced quality, then the reason for this is to be found in lack of redundancy and the model can not change this fact.5 In Fig. EA the software model of the modularized software object is shown.The software model consists of a class bendmnd configObj which has the operations construct () and destruct (). Construct () and destruct () are used to create a single modular software object, respectively, The modular software object has been described above in connection with Figs. 6B-6D.

Det i Fig. 1 visade systemets hardvarumodell beskrivs med hanvisning till Fig. 8. Hardvarumodellen 30 beskriver de fysiska organen och deras platser i systemet. Hardvarumodellen 30 inne- 15 fattar en klass Processor 31 vilken alstrar objekt som representerar processorerna P1-P4, en klass CPPool 32 vilken genererar objekt som representerar ndtet Ni, en klass DevX 33 som genererar objekt vilka representerar natet N2 och en klass ConfigObj 34 som genererar objekt vilka representerar mjuk- 20 varuobjekten, visade i Fig. 6B, av de ovan ndmnda organen; inklusive organprocessorerna. Klassen ConfigObj 35 alstrar objekt som representerar mjukvaruobjekten av det modulariserade mjukvaruobjektet i Fig.6A men bildar inte nagon del av hardvarumodellen. The hardware model of the system shown in Fig. 1 is described with reference to Fig. 8. The hardware model 30 describes the physical means and their locations in the system. The hardware model 30 includes a class Processor 31 which generates objects representing the processors P1-P4, a class CPPool 32 which generates objects representing ndtet Ni, a class DevX 33 which generates objects which represent nat N2 and a class ConfigObj 34 which generates objects representing the software objects, shown in Fig. 6B, by the above-mentioned means; including the body processors. The ConfigObj 35 class generates objects that represent the software objects of the modularized software object in Fig. 6A but does not form part of the hardware model.

Modellen visar att processorerna är anslutna till Ni och till N2. Modellen visar ocksa att mjukvara som inte har nagra organ kan installeras pa alla processorer som kan anslutas till Ni, medan mjukvara som styr organ maste installeras pa processorer • • • •• • • • • • • • • •• • •• • • • • • • rsom kan anslutas till N2. Modellen definierar restriktionerna • • ••• • • ••• •• • •• ••• • • • • for vane hardvaruberoende mjukvaruobjekt. Genom att ansluta ConfigObj till DevX (Organ X) inkluderas inte bara hardvaru- 23 :"":: • .' ": • • •00 •00 00 0000 00 anordningarna i hardvarumodellen utan samtidigt installeras de organstyrande mjukvaruobjekten i modellen. The model shows that the processors are connected to Ni and to N2. The model also shows that software that does not have any devices can be installed on all processors that can be connected to you, while software that controls devices must be installed on processors • • • •• • • • • • • • • • • • • • • • • • r which can be connected to N2. The model defines the restrictions • • ••• • • ••• •• • •• ••• • • • • for habit hardware-dependent software objects. Connecting ConfigObj to DevX (Organ X) not only includes hardware 23: "" :: •. ' ": • • • 00 • 00 00 0000 00 devices in the hardware model but at the same time the organ control software objects are installed in the model.

• • ••• •••••••••• •••• • •• •• • • • • • • • ••••III• IS• II... •• 11.•••• I;.11 • : •••••• ••• •••• Tabell 1 INITIAL KONFIGURATON PROCESSOR-ID OBJEKT-ID 1 1,2,3 2 4,5,6,7 3 8,9,10,11, 12 4 13, 14,15,16, 17, 18 Tabell 2 KATASTROFPLAN for processor 1(KP-P1) OBJEKT-ID PROCESSOR-ID 1 2 2 4 3 2 Tabell 3 KATASTROFPLAN for processor 2(KP-P2) OBJEKT-ID PROCESSOR-ID 4 1 3 6 3 7 4 • • • • • • 24 ••• ••••• •••••••: •••• •••••••• • •• • • • •• •• • •• •• : •• *.* ••• ..• • : • •••••••• • • • :•• ••• ••• Tabell 4 KATASTROFPLAN for processor 3(KP-P3) OBJEKT-ID PROCESSOR-ID 8 1 9 1 2 11 4 12 4 Tabell KATASTROFPLAN for processor 4(KP-P4) OBJEKT-ID PROCESSOR-ID 13 2 14 1 2 ' 16 1 17 2 18 1 • •• • • • • • ••• • • ••• ••••••••••••: •••••••• •• •• •• • •• ••• •••• • ••• • • • •• •• •• •• •• • • ••• 26 :*.• : •••••••• :•• ••• Tabell 6 AKTUELL KONFIGURATIONSTABELL nar processor 1 är trasig PROCESSOR-ID OBJEKT-ID 2 1, 3,4,5,6, 7 3 8, 9,10,11 12 4 2, 13, 14,15,16, 17, 18 Tabell 7 DELTAKONFIGURATION for processor 1 PROCESSOR-ID OBJEKT-ID 2 1,3, 3 - 4 2 •• • • • • • ••• • • • • :••• •• • • •• •• • •••• • •• • •• •• • •• •• •• • 27 • •• : •• •• 7 • ••• • • • •• •••••••• •• •• • •• • :•• • ••• ••• Tabell 8 Ny KATASTROFPLAN fOr processor 2(KP-P2' ) OBJEKT-ID PROCESSOR-ID 1 3 3 3 4 3 4 6 4 7 4 Tabell 9 • • • •• • •• • • • • • • •• • • • • • ••• • • ••• ••• • • • • Ny KATASTROFPLAN for processor 3(KP-P3' ) - OBJEKT-ID PROCESSOR-ID 8 2 9 2 4 11 4 12 4 • • • •• ••• • ••• • • •• ••• • •••• •• • • • • ••••• 28 4001• • • • • • • • • .• • •• • • •• •• 0 • • • Tabell Ny KATASTROFPLAN for processor 4(KP-4') OBJEKT-ID PROCESSOR-ID 2 2 13 2 14 2 2 16 3 17 3 18 3 Tabell 11 Ny AKTUELL KONFIGURATIONSTABELL nar processor 2 är trasig PROCESSOR-ID OBJEKT-ID 3 1, 3, 4, 8,9,10, 11, 12 4 2, 5, 6, 7, 13,14,15, 16, 17, 18 ••• VI%•••: •••• •••• •••• •••• • • • •• ••• • ••• • • •• •••• •••• •• • • • • ••••• : : 7..••••• •:•• ••• • • ••• •••••••••• •••• • •• •• • • • • • • •••• III • IS • II ... •• 11. ••• • I; .11 •: •••••• ••• •••• Table 1 INITIAL CONFIGURATON PROCESSOR ID OBJECT ID 1 1,2,3 2 4,5,6,7 3 8,9,10 , 11, 12 4 13, 14,15,16, 17, 18 Table 2 DISASTER PLAN for processor 1 (KP-P1) OBJECT ID PROCESSOR ID 1 2 2 4 3 2 Table 3 DISASTER PLAN for processor 2 (KP-P2) OBJECT ID PROCESSOR ID 4 1 3 6 3 7 4 • • • • • • 24 ••• ••••• ••••••• • •••• ••••••• • • • • • • •• •• • •• ••: •• *. * ••• .. • •: • •••••••• • • •: •• ••• ••• Table 4 DISASTER PLAN for processor 3 (KP-P3) OBJECT ID PROCESSOR ID 8 1 9 1 2 11 4 12 4 Table DISASTER PLAN for processor 4 (KP-P4) OBJECT ID PROCESSOR ID 13 2 14 1 2 '16 1 17 2 18 1 • •• • • • • • ••• • • ••• •••••••••••• • •••••••• •• •• •• • •• •• • •••• • ••• • • • •• •• •• •• •• • • ••• 26: *. •: ••••••••• • •• ••• Table 6 CURRENT CONFIGURATION TABLE when processor 1 is broken PROCESSOR ID OBJECT ID 2 1, 3,4,5,6, 7 3 8, 9,10,11 12 4 2, 13, 14,15,16, 17, 18 Table 7 PARTICIPATION CONFIGURATION for proc essor 1 PROCESSOR ID OBJECT ID 2 1,3, 3 - 4 2 •• • • • • • ••• • • • •: ••• •• • • •• •• • •••• • • • • •• •• • •• •• •• • 27 • ••: •• •• 7 • ••• • • • •• •••••••• •• •• • •• •: •• • ••• ••• Table 8 New DISASTER PLAN FOR PROCESSOR 2 (KP-P2 ') OBJECT ID PROCESSOR ID 1 3 3 3 4 3 4 6 4 7 4 Table 9 • • • •• • •• • • • • • • •• • • • • ••• • • ••• ••• • • • • New DISASTER PLAN for processor 3 (KP-P3 ') - OBJECT ID PROCESSOR ID 8 2 9 2 4 11 4 12 4 • • • •• ••• • ••• • • •• ••• • •••• •• • • • • • ••••• 28 4001 • • • • • • • • • . • • •• • • •• •• 0 • • • Table New DISASTER PLAN for processor 4 (KP-4 ') OBJECT ID PROCESSOR ID 2 2 13 2 14 2 2 16 3 17 3 18 3 Table 11 New CURRENT. CONFIGURATION TABLE when processor 2 is broken PROCESSOR ID OBJECT ID 3 1, 3, 4, 8,9,10, 11, 12 4 2, 5, 6, 7, 13,14,15, 16, 17, 18 •• • WE%•••: •••• •••• •••• •••• • • • •• ••• • ••• • • •• •••• •••• •• • • • • •••••:: 7 .. ••••• •: •• •••

Claims

CLAIMS 1. Software model for a distributed processor system in a software-driven telecommunication system, which includes Svalve hardware, including first processors, other organ controlling processors and means controlled by the other processors as software may be characterized by a software-produced model of the system's hardware cooperating with a software developed model of the system's software. Software model according to claim 1, characterized in that the software of the software model is divided into software modules, called software objects, that the software modules are provided with properties that make them movable between processors in the processor system, that the software modules are assigned individual identities, that processors are assigned individual identities. that the habit processor has its own identity, and that the software modules are installed on different of the said first and second processors for producing an initial configuration. Software model according to claim 2, characterized in that the habitual software module is provided with at least two functions, one of which creates the software object and the other kills the software object. 29 1. • • 2. •• 3. • • 4. • 5. • • 6. •• 7. • •• • 8. • • 9. • 10. • ..... 11. • 4. A software model according to claim 3, characterized in that software modules that are independent of hardware comprise a resource object. Software model according to claim 1, characterized by 1.. 2. • •. •. • that the initial configuration is created by mapping software • • •• • ••• 6. • • 7. • • ject, which executes on an individual processor, is mapped to the named •• • •• ••• •••: • • •• ••• 00. •••• 8. •: •• •• •• • 9. • 10. •. • •••• ■■ • 11 • individual processor and that said mapping is repeated for each of the processors in the processor system. Software model according to claim 4, characterized in that the redistribution step comprises the creation and start of the software objects redistributed in accordance with the disaster plan for the failed processor. Software model according to claim 6, characterized in that first software objects controlling hardware equipment, which the failed processor controls, are first redistributed, and then software objects which do not control hardware equipment are redistributed. Software model according to claim 7, characterized by blocking of software objects which exhibit a hardware dependency and which execute on a failed processor against access from software objects which execute on other operable processors in the processor system. Software model according to claim 8, characterized in that a processor having a hardware dependency is represented by a software object.

1. • •

2. • •

3. • •

4. • • • •• ••• • ••• • • •• -Go ,. • ••••• •• •• •• •••••:: ••••••: • • • ••• •• •• •••• •• SUMMARY A procedure for automatic recovery from multiple permanent processor failures in a distributed processor system, in particular software-driven telecommunications systems. The method involved generating an initial configuration describing each processor and software object executing thereon, and, for each processor, establishing a contingency plan to be followed in the event of the processor failing. An emergency plan contains information indicating how the software objects executing on the failed processor should be redistributed on functional processors in the system. If a processor fails, its software objects are moved to operational processors in accordance with the disaster plan for the failed processor. A hardware and software model of the processor system and its software is described. A software object that carried a hardware dependency is handled by the model. 31

5. •

6. • •

7. • •

8. • • • • •

9. •

10. • •

11. ••

12. • •• •

13. • •

14. •

15. • •• •

16. • •

17. • •

18. ••

19. •

20. • •••: •• :: •••% it. ••: ••• .:: ••:. ::. ••• :: ••: ••••••

21. • ••• • • :::: • ••:. • ::: 7 .. ': •••• ••••••