SE470456B - Operations support for telecommunications and open systems - Google Patents

Abstract

The invention concerns an operations support network with at least one operations support system 2 and at least one handled system 10 for telecommunications or open systems. The abovementioned handled system contains physical and/or logical resources which are regarded and handled by the operations support system as controlled objects in the form of data images of the resources. For its operations directed towards the handled system, the operations support system utilizes an operations support information model 8 of the handled system, which contains a description of all the controlled objects adapted to the way of working of the operations support system. The operations support network comprises in addition to the handled system 10 a general operations support handler 4 and a representation 6 of the operations support information model, where the behaviour of the general handler during operation is determined by this model representation. <IMAGE>

Description

Jb» CJ' l Q\ M.3000-serien. Jb » CJ 'l Q \ M.3000 series.

TMN betraktar alla nätnoder som nätelement (NE). Dessa nätelement är utförda som telefonväxlar och transmissions- eller transportnätprodukter.TMN considers all network nodes as network elements (NE). These network elements are designed as telephone exchanges and transmission or transport network products.

Den funktionella strukturen hos TMN innefattar - driftstödfunktioner (OSF, Operations Support Functions), vilka hanterar tillämpningsprogram tillgängliga för användare, såsom stödfunktioner för "Business Management" och tjänste- och nätadministration; - datakommunikationsfunktioner (DCF, Data Communications Functions), vilka hanterar datakommunikationen mellan driftstöd- systemen OSS och de hanterade systemen NE; - förmedlingsfunktioner (MF, Mediation Functions), vilka om- vandlar information (mellan exempelvis styrda objekt), hanterar data, koncentrerar, reducerar, och editerar, fattar beslut avseende t.ex. tröskelvärden, samt lagrar data, som identifierar utrustning och nät; - nätelementfunktioner (NEF, Network Element Functions), vilka hanterar telekomprocesser såsom växelfunktioner och trans- mission, samt deltar i stödprocesser för telekommunikationer, såsom fellokalisering och skyddskopplingar; - funktioner för gränssnittsanpassning (QAF, Q-Adapter Func- tions), vilka utför omvandling av gränssnitt från icke-standard till standard; - arbetsstationsfunktioner (WSF, Working Station Functions), vilka utgör TMN:s användarterminaler, visar information och hjälper drifttekniker att hantera nätet.The functional structure of TMN includes - Operations Support Functions (OSF), which manages application programs available to users, such as support functions for "Business Management" and service and network administration; data communication functions (DCF, Data Communications Functions), which handle the data communication between operating the OSS systems and the managed systems NE; - Mediation Functions (MF), which converts information (between controlled objects, for example), handles data, concentrate, reduce, and edit, make decisions regarding e.g. threshold values, as well as stores data, which identifies equipment and networks; - Network Element Functions (NEF), which handle telecom processes such as switching functions and mission, and participates in support processes for telecommunications, such as fault location and protective couplings; Interface Adaptation Functions (QAF, Q-Adapter Func- which perform the conversion of interfaces from non-standard to standard; - Working Station Functions (WSF), which constitute TMN's user terminals, display information and helps operations technicians manage the network.

TMN innefattar även ett gränssnitt, kallat Q3. Q3 är förutom kommunikationsprotokoll även en informationsmodell, som innefat- tar datascheman, -operationer och -notifikationer. De närmare detaljerna hos Q3-gränssnittet och dess protokoll framgår av CCITT-rekommendationerna Q96l och Q962.TMN also includes an interface called Q3. Q3 is in addition communication protocol also includes an information model, which includes takes data schedules, operations, and notifications. The closer the details of the Q3 interface and its protocols are shown in CCITT Recommendations Q961 and Q962.

TMN betraktar alla fysiska och logiska objekt såsom styrda objekt, som av TMN benämns M0 (Managed Object), en benämning, som även här fortsättningsvis omväxlande kommer att användas.TMN considers all physical and logical objects as controlled objects, which by TMN is called M0 (Managed Object), a name, which will continue to be used interchangeably here as well.

Styrda objekt är databilder av sådana fysiska eller logiska resurser som ledningar, kretsar, signalterminaler, överförings- vägar, händelseloggar, larmrapporter, etc.Controlled objects are data images of such physical or logical resources such as lines, circuits, signal terminals, transmission roads, event logs, alarm reports, etc.

Ett specifikt förhållande uppträder mellan en resurs och ett 470 456 3 styrt objekt. En resurs kan vara relaterad till ett eller flera MO eller inget alls. Omvänt kan ett M0 vara relaterat till en eller flera resurser, eller ingen alls. Detta förhållande är viktigt om ett M0 påverkas av någon form av drift- eller under- hållsaktivitet. Ett M0 får ej avlägsnas innan de funktioner, under vilket det är underordnat, själva har avlägsnats. Denna informationsmodell är grundad på objektorientering och rela- tionsbegreppet.A specific relationship occurs between a resource and a 470 456 3 controlled object. A resource can be related to one or more MO or nothing at all. Conversely, an M0 may be related to one or more resources, or none at all. This relationship is important if an M0 is affected by some form of operational or holding activity. An M0 must not be removed before the functions under which it is subordinate, themselves have been removed. This information model is based on object orientation and rela- the concept of tion.

Driftstödsystemet (OSS - Operation Support System) behandlar nätelement och underordnade driftstödsystem som en samling styrda objekt i en tänkt databas kallad MIB (Management Informa- tion Base). Dessa styrda objekt utgörs av instanser av en M0- klass, såsom ett antal signalterminaler av samma typ. Varje terminal kommer sålunda att utgöra en instans av klassen signal- terminal.The Operation Support System (OSS) handles network elements and subordinate operational support systems as a collection controlled objects in an imaginary database called MIB (Management Information tion Base). These controlled objects consist of instances of an M0- class, such as a number of signal terminals of the same type. Each terminal will thus constitute an instance of the signal terminal.

I TM förekommer även begreppet MIM (Management Information Model), som hänför sig kollektivt till all information avseende styrda objekt. MIM är en modell av alla attribut, relationer, operationer och notifikationer hänförliga till styrda objekt.In TM, the term MIM (Management Information) also appears Model), which refers collectively to all information concerning controlled objects. MIM is a model of all attributes, relationships, operations and notifications attributable to controlled objects.

För att kunna söka efter MO-instanser används ett driftstödin- formationsträd MIT (Management Information Tree). Denna träd- struktur börjar i nätet och pekar ut nätelement och abonnenter eller utrustning.In order to be able to search for MO instances, an operating aid formation tree MIT (Management Information Tree). This tree structure begins in the network and points out network elements and subscribers or equipment.

För drift- och underhåll representeras varje separat enhet eller resurs, om vilken information krävs, eller vars operation påverkas från systemets utsida, av ett styrt objekt. Varje informationsutbyte hänförligt till hantering av operationer eller enheter, vilka måste påverkas eller rapportera något (såsom uppsättning av data, tilldelning av namn, eller hantering av larm) sker i form av operationer på eller notifikationer från styrda objekt.For operation and maintenance, each separate unit is represented or resource, about which information is required, or whose operation affected from the outside of the system, by a controlled object. Each information exchange relating to the management of operations or entities, which must be affected or report something (such as data set, name assignment, or management of alarms) takes place in the form of operations on or notifications from controlled objects.

Ett styrt objekt innehåller attribut och kan även uppvisa en relation till andra styrda objekt. Ett antal olika operationer kan riktas mot ett styrt objekt och händelser kan genereras av sådana objekt.A controlled object contains attributes and can also display one relation to other controlled objects. A number of different operations can be aimed at a controlled object and events can be generated by such objects.

I det följande skall en redogörelse för brister hos TMN ges.In the following, an account of deficiencies in TMN shall be given.

Nätelement och underordnade driftstödsystem hanteras av ett driftstödsystem medelst operationer mot styrda objekt i de hanterade systemen och övervakning av notifikationer, som ut- "Pa C .TI Ü '\ 4 sänds av det hanterade systemet.Network elements and subordinate operating support systems are handled by one operational support systems by means of operations against controlled objects in the managed the systems and monitoring notifications, which "Pa C .TI Ü '\ 4 sent by the managed system.

Tillåtna operationer mot styrda objekt i det hanterade systemet bestäms av en informationsmodell av det hanterade systemet, tillsammans med vilka notifikationer, som kan utsän- das. Informationsmodellen anger: - vilka klasser av styrda objekt som är definierade, - vilka operationer de styrda objekten i dessa klasser accepterar, - vilka notifikationer som de styrda objekten förväntas utsända, - hur många instanser som kan skapas eller avlägsnas i varje klass av styrda objekt, - beroenden mellan styrda objekt, t.ex. att ett styrt objekt kräver existens av ett annat, - beroenden i ett styrt objekt, t.ex. att ett visst attri- butvärde hos ett attribut endast tillåts om ett annat attribut är inställt på ett visst värde eller att det styrda objektet endast kan avlägsnas om det befinner sig i ett visst tillstånd, - ändamålet och meningen med styrda objekt och deras not- ifikationer.Permitted operations against controlled objects in the managed the system is determined by an information model of the managed system, together with the notifications that may be sent das. The information model states: - which classes of controlled objects are defined, - which operations the controlled objects in these classes accepts, - which notifications the controlled objects are expected broadcast, - how many instances can be created or removed in each class of controlled objects, - dependencies between controlled objects, e.g. that a controlled object requires the existence of another, dependencies in a controlled object, e.g. that a certain attraction but value of one attribute is only allowed if another attribute is set to a certain value or to the controlled object can only be removed if it is in a certain condition, - the purpose and meaning of controlled objects and their notation ifications.

För att vara meningsfullt måste driftstödsystemet känna till informationsmodellen av det hanterade systemet. Detta benämns i TMN "shared management knowledge".To be meaningful, the operational support system must know the information model of the managed system. This is called in TMN "shared management knowledge".

Vid ändring av informationsmodellen måste driftstödsystemet uppdateras i enlighet med denna ändring. I konventionella system sker dessa ändringar genom: - Definition av den nya informationsmodellen. Detta sker genom specifikationer för styrda objekt skrivna som GDMO/ASN.1- mallar (GDMO - Guidelines for the Definition of Managed Objects enligt CCIT rec. X.722 ISO/IEC 10165-4) samt ER-diagram (Entity- Relationship diagrams) för de styrda objekten. Specifikationerna för de styrda objekten anger formellt (maskinläsbart) syntax (t.ex. operationer och notifikationer) för det styrda objektet.When changing the information model, the operating support system must updated in accordance with this amendment. In conventional systems these changes are made by: - Definition of the new information model. This takes place through specifications for controlled objects written as GDMO / ASN.1- templates (GDMO - Guidelines for the Definition of Managed Objects according to CCIT rec. X.722 ISO / IEC 10165-4) and ER chart (Entity Relationship diagrams) for the controlled objects. The specifications for the controlled objects indicates formal (machine-readable) syntax (eg operations and notifications) for the controlled object.

Alla andra delar av informationsmodellen, såsom beroenden, antalet instanser etc., anges informellt som kommentarer i naturligt språk.All other parts of the information model, such as dependencies, the number of instances, etc., is stated informally as comments in natural language.

- Implementering och verifiering av den nya informations- modellen i driftstödsystemet och det hanterade systemet.- Implementation and verification of the new information the model in the operational support system and the managed system.

- Bekräftelse av att driftstödsystem och hanterade system är 479 456 5 anpassade till samma informationsmodell, genom utförande av godkända provningsföljder.Confirmation that operational support systems and managed systems are 479 456 5 adapted to the same information model, by performing approved test results.

- Uppdatering av det av driftstödsystem och hanterade system bestående nätet med denna nya version av informationsmodellen.Update of the operating support systems and managed systems existing network with this new version of the information model.

Det nyss sagda medför ett antal problem: För det första måste utvecklingen av driftstödsystem och hanterade system koordineras, vilket leder till högre utveck- lingskostnader och/eller försenat införande av nya tjänster på marknaden.What has just been said poses a number of problems: First, the development of operational support systems and managed systems are coordinated, leading to higher costs and / or delayed introduction of new services on market.

För det andra gör frånvaron av formalism med avseende på de hanterade systemens specifikationer implementering, verifiering och godkännande av både driftstödsystem och hanterade system till en kinkig och tidskrävande uppgift, eftersom specifikatio- nernas tolkning kan diskuteras.Second, the absence of formalism with respect to those managed system specifications implementation, verification and approval of both operational support systems and managed systems to a tricky and time-consuming task, as the specification interpretation can be discussed.

För det tredje måste uppgradering av nät omsorgsfullt plane- ras och utföras, eftersom det föreligger beroenden mellan olika versioner av driftstödsystem och hanterade system. Detta medför fördröjd introduktion av nya tjänster i nätet. Ändamålet med driftstöd enligt TMN-modellen är att vara ett ramverk för standardisering av driftstöd för telenät och öppna system. Driftstödstrukturen påverkar starkt driftstödparadigmet för nya systemarkitekturer. Det finns starka skäl för att anta driftstödparadigmet enligt TMN-modellen för hela driftstödet och inte bara för områden utsatta för standardisering. Huvudskälet till detta är att det är önskvärt att på ett enhetligt sätt kunna utveckla och konstruera driftstödfunktioner.Third, network upgrades must be carefully planned race and performed, because there are dependencies between different versions of operational support systems and managed systems. This causes delayed introduction of new services in the network. The purpose of operating support according to the TMN model is to be one framework for standardizing operating support for telecommunications networks and open system. The operational support structure strongly influences the operational support paradigm for new system architectures. There are strong reasons to assume the operational support paradigm according to the TMN model for the entire operational support and not just for areas subject to standardization. The main reason to this is that it is desirable to in a uniform manner be able to develop and construct operational support functions.

Beskrivning av uppfinningen.Description of the invention.

Ett första syfte med föreliggande uppfinning är allmänt att ange en ny arkitektur för driftstödfunktioner, som medger - kostnadseffektiv konstruktion av driftstödfunktioner, - mindre behov av koordinering och planering av uppdateringar av driftstödfunktion och resurser, - effektivt stöd av komplexa processer, såsom nätdriftstöd, - att driftstödteknologin kan utvecklas separat i förhållande till resursteknologin, - att olika kompetens kan utnyttjas optimalt, dvs en expert på exempelvis resursområdet fokuserar sina insatser till detta område, medan en person, som kan driftstödkonstruktion, sysslar ..§.*:~. 75* 6 med detta.A first object of the present invention is generally that specify a new architecture for operational support functions, which allows - cost-effective design of operational support functions, - less need for coordination and planning of updates of operational support function and resources, - efficient support of complex processes, such as network operating support, - that the operational support technology can be developed separately in relation to resource technology, - that different skills can be used optimally, ie an expert in the area of resources, for example, focuses its efforts on this area, while a person who can support construction, is engaged ..§. *: ~. 75 * 6 with this.

Detta syfte liksom andra syften, som kommer att framgå av nedan givna beskrivning, uppnås enligt en första aspekt av uppfinningen genom att det inledningsvis definierade driftstöd- nätet förutom det hanterade systemet innefattar en generell driftstödhanterare och en representation av driftstödsinforma- tionsmodellen, där den generella hanterarens uppträdande under drift bestäms av denna modellrepresentation.This purpose as well as other purposes, which will be apparent from description given below, is achieved according to a first aspect of the invention in that the initially defined operating aid the network in addition to the managed system includes a general operational support manager and a representation of operational support information model, where the behavior of the general manager during operation is determined by this model representation.

Enligt en andra aspekt uppnås nämnda syften genom att det hos ifrågavarande driftstödnät i det hanterade systemet implemente- ras en representation av driftstödsinformationsmode1len som instanser av en speciell klass av styrda objekt.According to a second aspect, said objects are achieved by the operational support network in question in the managed system a representation of the operational support information model1 as instances of a special class of controlled objects.

Enligt en tredje aspekt uppnås nämnda syften genom att det ifrågavarande driftstödsnätet kännetecknas av att driftstödsinformationsmodellens specifikation är i form av en bestämbar representation av driftstödsinformationsmodellen, vilken senare definierar - vilka tillstånd av intresse från driftstödsynpunkt det hanterade systemet kan anta, - vilka operationer som kan accepteras av det hanterade systemet, - vilka operationer som kan riktas mot ett hanterat system i ett visst tillstånd, samt slutligen - vilket tillstånd det hanterade systemet uppnår när det utsätts för en viss operation, varvid med en bestämbar representation avses att ovanstående definitioner skall kunna uttryckas i ett maskintolkningsbart språk, ledande till att ovannämnda egenskaper kan bestämmas från specifikationen, samt att, för att definiera tillståndet hos ett visst hanterat system sker definition av: - vilka instanser av hanterade objekt, som kan existera och - vilka attribut de har och - vilka värden dessa attribut kan ha.According to a third aspect, said objects are achieved by the operational support network in question is characterized by: the specification of the operational support information model is in the form of a determinable representation of the operational support information model, which later defines which states of interest from the point of view of operational support managed system can assume, - which operations can be accepted by the managed the system, which operations can be directed at a managed system in a certain condition, and finally - what condition the managed system achieves when it subjected to a certain operation, whereby a definable representation means that the above definitions must be able to be expressed in a machine-interpretable language, leading to the above properties being determined from the specification, and that, to define the state of a particular managed system is defined by: which instances of managed objects, which can exist and what attributes they have and - what values these attributes can have.

Enligt en fjärde aspekt uppnås nämnda syften genom att det ifrågavarande driftstödnätet kännetecknas av en generell drift- stödhanterare, som innehåller funktioner som möjliggör att en yttre användare kan interagera med det hanterade systemet genom att manipulera representationer av det hanterade systemets fa 479 4 O driftstödsinformationsmodell.According to a fourth aspect, said objects are achieved by the operational support network in question is characterized by a general support manager, which contains features that enable a external users can interact with the managed system through to manipulate representations of the managed system fa 479 4 O operational support information model.

Olika fördelaktiga utföringsformer av uppfinningen har erhållit de i respektive beroende patentkrav angivna känneteck- nen.Various advantageous embodiments of the invention have obtained the characteristics specified in the respective dependent claims nen.

Genom uppdelningen av driftstödsystemet uppnås följande fördelar: - den generella driftstödhanteraren kan återanvändas för flera driftstödfunktioner för flera tillämpningar i det hante- rade systemet; - den generella driftstödhanteraren påverkas ej av ändringar i informationsmodellen: - heterogena nät med hanterat system i olika versioner och med olika funktioner kan hanteras av samma enda generella drift- stödhanterare.The division of the operating support system achieves the following benefits: the general operating support manager can be reused for multiple operational support functions for multiple applications in the rade system; the general operating support manager is not affected by changes in the information model: heterogeneous networks with managed systems in different versions and with different functions can be handled by the same single general operating support managers.

Fördelarna med implementeringen av en representation av informationsmodellen i det hanterade systemet är följande: - Representationen lagras alltid i en nod i nätet.The benefits of implementing a representation of the information model in the managed system is as follows: - The representation is always stored in a node in the network.

- Representationen överensstämmer alltid med modellen av det hanterade systemet.- The representation always corresponds to the model of it handled the system.

- Lätt hantering av den delade driftstödkännedomen "shared managementlknowledge".- Easy handling of the shared operating support knowledge "shared managementlknowledge ".

- Lätt hantering av uppgraderingar av system och nät.- Easy handling of system and network upgrades.

- Uppgraderingar av system och nät kan ske utan driftstör- ningar. Det uppträder inga tidsluckor, i vilka driftstödsystemet och hanterat system har olika åsikter om vilken informationsmo- dell som är giltig.- Upgrades of systems and networks can take place without nings. There are no time slots in which the operating support system and managed systems have different views on which information valid.

Ett antal fördelar följer med att göra en specifikation av informationsmodellen i form av en bestämbar representation av informationsmodellen.A number of benefits come with making a specification of the information model in the form of a definable representation of the information model.

- Den generella driftstödhanteraren kan göras kraftfullare, eftersom den kan förutsäga det hanterade systemets nya tillstånd efter en viss operation, och den kan även föreslå vilka opera- tioner som tillåts i ett visst tillstånd.- The general operating support manager can be made more powerful, as it can predict the new state of the managed system after a particular operation, and it may also suggest which operations permitted in a particular state.

- Implementationen och verifikationen av det hanterade systemet liksom driftstödtillämpningar förenklas eftersom det väntade uppträdandet är väl specificerat. Generering av en stor del av implementeringskoden från speficikationen möjliggörs även.- The implementation and verification of what is managed system as well as operational support applications are simplified because it expected behavior is well specified. Generation of a large part of the implementation code from the specification is made possible also.

- Robustheten under drift förbättras eftersom endast opera- ~.._;_| "Û L- . En L? 'l (LN 8 tioner ledande till tillåtna tillståndsövergångar i det hantera- de systemet accepteras.- The robustness during operation is improved because only ~ .._; _ | "Û L- . One L? 'l (LN 8 leading to permissible state transitions in the management the system is accepted.

- Tidig emulering och värdering av informationsmodellen förenklas, vilket gör specifikationsuppgiften lättare.- Early emulation and evaluation of the information model simplified, which makes the specification task easier.

- Driftstödmodellen kan formas till att vara mer robust och lätt att använda, genom att medge en ganska fri följd av opera- tioner men fortfarande garantera en komplett konfigurering av det hanterade systemet, innan konfigureringen sätts till opera- tivt tillstånd.- The operational support model can be shaped to be more robust and easy to use, by allowing a fairly free sequence of operations but still guarantee a complete configuration of the managed system, before the configuration is set to the active condition.

Beskrivning av ritningarna.Description of the drawings.

Ett antal utföringsformer av uppfinningen skall nu beskrivas närmare nedan med hänvisning till bifogade ritningar, på vilka fig. 1 i blockschemaform åskådliggör en av uppfinningens huvudprinciper, fig. 2 är ett flödesschema över framställning av en av blockenheterna i fig. 1, fig. 3 är ett blockschema över arkitekturen hos driftstödnä- tet enligt uppfinningen, fig. 4 är ett blockschema över en av enheterna i fig. 3, fig. 5 är en bild avsedd att åskådliggöra ett styrande drift- stödsystems vy av en resurs, fig. 6 är en bild åskådliggörande relationen mellan typ- och instansnivå, fig. 7 och 8 är bilder som åskådliggör hur flera enheter på instansnivå delar på en gemensam enhet på typnivå i ett första resp. andra system, fig. 9 är en bild, som åskådliggör ett styrande driftstödsys- tems vy av de båda systemen enligt fig. 7 och 8, fig. 10 är en bild, som åskådliggör exempel på en informa- tionsmodell, som lagras i en typenhet, fig. 11 beskriver en operation, som det styrande driftstöd- systemet kan utföra genom tolkning av resursrepresentationen i fig. 10, fig. 12 åskådliggör ändring av informationsmodellen, fig. 13 visar exempel på operation, som strider mot informa- tionsmodellerna i såväl fig. 10 som fig. 12, och som aldrig skulle riktas mot det hanterade systemet, fig. 14 i blockschemaform åskådliggör hur gammal och ny 470 455 9 teknologi kan samexistera i en driftstöddomän med två styrande driftstödsystem, fig. 15 i blockschemaform visar en driftstödsystemenhet ingående i ett ramverk, som erhålles genom den i fig. 1 och åskådliggjorda uppfinningsprincipen, fig. 16 är en bild, som åskådliggör samverkan mellan en mänsklig användare och en representation av en resurs, fig. 17 i en liknande bild, som fig. 16 åskådliggör en ogiltig sådan samverkan, fig. 18 åskådliggör hur resursrepresentationer är organisera- de i en datastruktur, fig. 19 för åskådningsändamål i blockschemaform mycket schematiskt visar den allmäna uppbyggnaden av ett modelldrivet system bestående av driftstödsystem och hanterat system, fig. 20 schematiskt visar två objekttyper av olika klasser, fig. 21 i liknande vy som fig. 20 visar egenskaperna hos en vid utövande av uppfinningen använd speciell objekttyp, fig. 22 schematiskt åskådliggör sambandet mellan "normala" objektklasser, och objekt av den speciella objekttypen, för bildande av en driftstödinformationsmodel1 fig. 23 åskådliggör olika moment vid kodgenerering i samband med alstring av modellinformation, fig. 24-29 åskådliggör moment för att möjliggöra tolkning av information från en speciell objektklass i det hanterade syste- met, fig. 30-40 är definitioner i pseudokod, varvid fig. 30 är en definition av ett styrt objekt, fig. 31 visar hur potentiella attributvärden bestäms av attributens typ, fig. 32 är en definition av operationer, fig. 33 anger exempel på förvillkor, fig. 34 anger exempel på slutvillkor, fig. 35 anger exempel på slutvillkor där ett hanterat system kontrollerar konsistensen, fig. 36 anger exempel på slutvillkor där hanterat system vidmakthåller konsistensen, fig. 37 är en definition av ett objekt benämnt LineDriver, fig. 38 anger exempel på ett beroendeschema, fig. 39 anger exempel på ett slutvillkor, som är anslutet à å I” I I .: f : Q (JH I LL - 10 till en metod, fig. 40 anger exempel på ett slutvillkor, som är anslutet till en skapa-operation, fig. 41-44 i block- och funktionsscheman rekapitulerar tillämpliga delar av vad som tidigare beskrivits med avseende på uppfinningen och dess olika aspekter, särskilt med hänvisning till fig. 3 och 4, fig. 45 ger exempel på syntax för specificering av typer av styrda objekt med attribut, metoder, samt för- och slutvillkor, fig. 46 och 47 med användning av samma syntax specificerar två olika objekttyper, fig. 48 likaledes med samma syntax specificerar beroenden mellan objekttyperna enligt fig. 46 och 47, fig. 49 i blockschemaform visar en begreppsmodell, som åskådliggör relationer mellan slut-/förvillkor och de koncept, på vilka de är tillämpbara, fig. 50 med användning av samma syntax som i fig. 45-47 ger exempel på specifikation av implementeringsmekanismer för att bevara beroendena mellan objekttyperna enligt fig. 46 och 47, fig. 51 likaledes med samma syntax specificerar ett attribut i objekttypen enligt fig. 46 som ett attribut härlett från ett attribut i den relaterade objekttypen enligt fig. 47, fig. 52 specificerar propageringen från det ena attributet till det andra i fig. 51, fig. 53 i flödesschemaform visar faserna av en transaktion med ingående konsistenskontroll, fig. 54 visar den publika delen av en deklarationsfil, som erhålles vid kompilering av objekttypen enligt fig. 46 till en klass i C++ -kod, fig. 55 likaledes i C++ visar implementeringen av en metod, som ingår i filen enligt fig. 54, fig. 56 i C++ visar den deklarationsfil, som genereras från specifikationerna enligt fig. 47 och 50, fig. 57 i C++ visar implementeringen av två metoder hos objektet i deklarationsfilen enligt fig. 56, fig. 58 i flödesschemaform visar algoritmen för utförande av operationer av en transaktion, i vilken kontroll av förvillkor ingår, fig. 59 i C++ visar en utvidgning av deklarationsfilen enligt 470 456 ll fig. 54 med en metod för att kontrollera förvillkoret för av- lägsnande av objekt, fig. 60 i C++ visar implementering av två metoder hos objek- tet enligt fig. 54, fig. 61-69 i blockschemaform åskådliggör problem, som kan uppträda vid användning av teknik enligt teknikens ståndpunkt i samband med konstruktion av driftstödsystem, varvid fig. 61-64 berör problem, som kan uppträda i samband med återanvändning av bibliotekskomponenter i de styrda objekten i hanterade system, fig. 65 och 66 hänför sig till problem, som kan uppträda vid implementering av ett hanterat system i en skiktad systemarki- tektur, fig. 67-70 åskådliggör hur man principiellt kan lösa pro- blemen enligt fig. 61-66 genom konstruktion av en särskild typ av objekt, som skall kunna samverka med okända framtida styrda objekt, fig. 71-74 för samma exempel, som ovan beskrivits i samband med figurerna 45-52 och med användning av samma pseudo-syntax specificerar konstruktionen av objekt enligt fig. 70-74, varvid objekttypen enligt fig. 47 antas tillhöra ett plattformssystem, fig. 75-80 visar implementering i programkoden C++ av bero- endena mellan de enligt fig. 71-74 konstruerade objekten.A number of embodiments of the invention will now be described further below with reference to the accompanying drawings, in which Fig. 1 illustrates in block diagram form one of the invention main principles, Fig. 2 is a flow chart of the manufacture of one of the block units in Fig. 1, Fig. 3 is a block diagram of the architecture of the operating support network; according to the invention, Fig. 4 is a block diagram of one of the units of Fig. 3; Fig. 5 is a view intended to illustrate a controlling operation support system view of a resource, Fig. 6 is a view illustrating the relationship between type and instance level, Figs. 7 and 8 are pictures illustrating how several units on instance level shares a common device at the type level in a first resp. other systems, Fig. 9 is a view illustrating a control operating operating system. system view of the two systems of Figs. 7 and 8, Fig. 10 is a view illustrating examples of an information model, which is stored in a type unit, Fig. 11 describes an operation by which the controlling operating aid the system can perform by interpreting the resource representation in Fig. 10, Fig. 12 illustrates a change in the information model, Fig. 13 shows examples of operation which contradict the information the models in both Fig. 10 and Fig. 12, and as never before would be directed at the managed system, Fig. 14 in block diagram form illustrates how old and new 470 455 9 technology can coexist in an operating support domain with two controllers operating support system, Fig. 15 in block diagram form shows an operating support system unit included in a framework obtained by the one in Fig. 1 and illustrated principle of invention, Fig. 16 is a view illustrating the interaction between a human user and a representation of a resource, Fig. 17 in a similar view as Fig. 16 illustrates one invalid such collaboration, Fig. 18 illustrates how resource representations are organized those in a data structure, Fig. 19 for viewing purposes in block diagram form very schematically shows the general structure of a model driven systems consisting of operational support systems and managed systems, Fig. 20 schematically shows two object types of different classes, Fig. 21 in a view similar to Fig. 20 shows the properties of a in the practice of the invention use special type of object, Fig. 22 schematically illustrates the relationship between "normal" object classes, and objects of the special object type, for formation of an operational support information model1 Fig. 23 illustrates various steps in code generation in connection with generation of model information, Figs. 24-29 illustrate steps for enabling interpretation of information from a particular object class in the managed system with, Figs. 30-40 are definitions in pseudocode, wherein Fig. 30 is a definition of a controlled object, Fig. 31 shows how potential attribute values are determined by attribute type, Fig. 32 is a definition of operations, Fig. 33 shows examples of preconditions, Fig. 34 shows examples of final conditions, Fig. 35 shows examples of end conditions where a managed system checks the consistency, Fig. 36 shows examples of final conditions where managed systems maintains consistency, Fig. 37 is a definition of an object called LineDriver, Fig. 38 shows an example of a dependency diagram, Fig. 39 shows an example of a final condition which is connected à å I ” IN IN .: f : Q (JH IN LL - 10 to a method, Fig. 40 shows an example of a final condition which is connected to a create operation, Figs. 41-44 in block and function diagrams recapitulate applicable parts of what has been previously described with respect to the invention and its various aspects, in particular with reference to Figs. 3 and 4, Fig. 45 provides examples of syntax for specifying types of controlled objects with attributes, methods, and prerequisites and end conditions, Figs. 46 and 47 using the same syntax specify two different object types, Fig. 48 likewise with the same syntax specifies dependencies between the object types according to Figs. 46 and 47, Fig. 49 in block diagram form shows a conceptual model, which illustrates the relationships between final / preconditions and the concepts to which they apply, Fig. 50 using the same syntax as in Figs. 45-47 examples of specification of implementation mechanisms to preserving the dependencies between the object types according to Figs. 46 and 47, Fig. 51 likewise with the same syntax specifies an attribute in the object type of Fig. 46 as an attribute derived from a attributes in the related object type according to Fig. 47, Fig. 52 specifies the propagation from one attribute to the second in Fig. 51, Fig. 53 in flow chart form shows the phases of a transaction with in-depth consistency control, Fig. 54 shows the public part of a declaration file, which obtained by compiling the object type according to Fig. 46 into a class in C ++ code, Fig. 55 also in C ++ shows the implementation of a method, contained in the file of Fig. 54, Fig. 56 in C ++ shows the declaration file generated from the specifications of Figures 47 and 50, Fig. 57 in C ++ shows the implementation of two methods in the object in the declaration file according to Fig. 56, Fig. 58 in flow chart form shows the algorithm for performing operations of a transaction, in which control of preconditions included, Fig. 59 in C ++ shows an extension of the declaration file according to 470 456 ll Fig. 54 with a method for checking the precondition for removal of objects, Fig. 60 in C ++ shows the implementation of two methods of according to Fig. 54, Figs. 61-69 in block diagram form illustrate problems that may occur behave when using technology according to the state of the art in in connection with the construction of operating support systems, whereby Figs. 61-64 concern problems which may occur in connection with reuse of library components in the controlled objects in managed systems, Figures 65 and 66 relate to problems which may occur in implementation of a managed system in a layered system archive tektur, Figs. 67-70 illustrate how one can in principle solve blemishes according to Figs. 61-66 by construction of a special type of objects, which should be able to interact with unknown future controlled object, Figs. 71-74 for the same example, as described above in connection with Figures 45-52 and using the same pseudo-syntax specifies the construction of objects according to Figs. 70-74, wherein the object type according to Fig. 47 is assumed to belong to a platform system, Figs. 75-80 show implementation in the program code C ++ of the ends between the objects constructed according to Figs. 71-74.

Beskrivning av utföringsformer.Description of embodiments.

Enligt ett av uppfinningens kännetecken sker en separation av driftstödsystemet i en generell driftstödhanterare och en repre- sentation av en informationsmodell av ett hanterat system.According to one of the features of the invention, a separation of the operational support system in a general operational support manager and a presentation of an information model of a managed system.

I fig. 1 åskådliggörs detta schematiskt. Driftstödsystemet betecknas där med 2. Den generella dríftstödhanterarens 4 upp- trädande bestäms av representationen 6 av informationsmodellen 8. Från modellrepresentationen 6 kan med andra ord den generella driftstödhanteraren 4 fatta beslut med avseende på vilka opera- tioner, som skall ske mot ett hanterat system 10, och kan avgöra vilka operationer, som krävs för att uppnå ett önskat tillstånd hos detta. Modellrepresentationen 6 används även för rätt tolk- ning och förpackning av data från resp. till det hanterade systemet 10.In Fig. 1 this is schematically illustrated. The operating support system denoted there by 2. The general operating aid operator 4 is determined by the representation 6 of the information model 8. In other words, from the model representation 6 can the general the operational support manager 4 make decisions as to which to a managed system 10, and can decide what operations are required to achieve a desired condition at this. The model representation 6 is also used for correct interpretation. and packaging of data from resp. to the managed the system 10.

När nya resurser införs i det hanterade systemet 10 behöver 4 (_21 .Yu UI (__) \ 12 endast modellrepresentationen 6 ändras.When new resources are introduced into the managed system 10 need 4 (_21 .Yu UI (__) \ 12 only the model representation 6 is changed.

Enligt ett annat av uppfinningens kännetecken införs (lagras) en representation av informationsmodellen i det hanterade syste- met.According to another feature of the invention, (stored) a representation of the information model in the managed system met.

För specificering och implementering av styrda objekt i systemet används ett maskintolkningsbart språk. I detta språk skrivs specifikationerna för de styrda objekten. Dessa specifi- kationer av styrda objekt bildar tillsammans specifikationen för driftstödsinformationsmodellen.For specification and implementation of controlled objects in the system uses machine-interpretable language. In this language the specifications of the controlled objects are written. These specifications cations of controlled objects together form the specification for the operational support information model.

Denna specifikation överförs till en kompilator, av vilken implementeringsstubkod och mellanformat för driftstödsinform- ationsmodellen genereras.This specification is transferred to a compiler, by which implementation stub code and intermediate format for operational support information the tion model is generated.

Implementeringsstubkoden förfinas eventuellt därpå manuellt och kompileras för att implementera det hanterade systemet.The implementation stub code may then be refined manually and compiled to implement the managed system.

Denna implementering förpackas därpå tillsammans med mellan- formatet av driftstödsinformationsmodellen, till laddningspaket.This implementation is then packaged together with intermediate the format of the operational support information model, to the charging package.

Detta laddningspaket laddas därpå in i målsystemet, d.v.s. det hanterade systemet. Under denna laddningsprocess används mellan- formatet av driftstödsinformationsmodellen för att skapa en representation av driftstödsinformationsmodellen.This charge packet is then loaded into the target system, i.e. the handled the system. During this charging process, intermediate the format of the operational support information model to create a representation of the operational support information model.

I det hanterade systemet implementeras representationen av driftstödsinformationsmodellen som instanser av en speciell klass av styrda objekt. Denna klass benämns nedan MIM-Server (Management Information Model Server). För varje klass av styrda objekt skapas en instans av MIM-Server-klassen.In the managed system, the representation of is implemented the operational support information model as instances of a special class of controlled objects. This class is hereinafter referred to as MIM Server (Management Information Model Server). For each class of controlled objects, an instance of the MIM Server class is created.

Skapandet av laddningspaket framgår schematiskt av fig. 2.The creation of the charge packet is schematically shown in Fig. 2.

Enligt fig. 2 skrivs i ett först moment 11 en specifikation 12 av det styrda objektet. I nästa moment 13 kompileras denna specifikation till en implementeringsstubkod 14 i C++ och till ett mellanformat 16 av objektsspefikationen. För närmare be- skrivning av språket C++ hänvisas till Margaret A Ellis, Bjarne Stroustrup: "The annotated C++ Reference Manual".According to Fig. 2, a specification 11 writes a specification 12 of the controlled object. In the next step 13 this is compiled specification to an implementation stub code 14 in C ++ and to an intermediate format 16 of the object specification. For further details writing of the language C ++ is referred to Margaret A Ellis, Bjarne Stroustrup: "The annotated C ++ Reference Manual".

Enligt moment 18 implementeras det styrda objektet i C++.According to step 18, the controlled object is implemented in C ++.

Denna implementation innefattar den skapade stubkoden, som innefattar mellanformatet av specifikationen. I moment 20 kompi- leras C++ implementationen till 22.This implementation includes the created stub code, which includes the intermediate format of the specification. At the moment 20 companies the C ++ implementation is taught to 22.

I moment 24 skapas en specifikation 26 av ett laddningspake- tet, i vilket implementationen av detta styrda objekt skall vidarebefordras, och i moment 28 genereras paketet 30.In step 24, a specification 26 of a charge package is created. in which the implementation of this controlled object is to be forwarded, and in step 28, the packet 30 is generated.

FÅ -I1 LÜ ms (IW Ö\ 13 Vid laddning av ett paket 30 i det hanterade systemet, skapas en ny instans av MIM-server-klassen för varje klass av styrda objekt, som implementeras av laddningspaketet.GET -I1 LÜ ms (IW ISLAND\ 13 When loading a packet 30 in the managed system, is created a new instance of the MIM server class for each class of controllers objects, which are implemented by the charge packet.

Enligt ett ytterligare av uppfinningens kännetecken utförs driftstödsinformationsmodellens specifikation som en bestämbar representation av driftstödsinformationsmodellen.According to a further feature of the invention is carried out the specification of the operational support information model as a determinable representation of the operational support information model.

Driftstödsinformationsmodellen anger - vilka tillstånd det hanterade systemet kan anta (tillstånd av intresse från driftstödsynpunkt), - vilka operationer som kan riktas mot det hanterade syste- met, - vilka operationer som kan riktas mot ett hanterat system i ett visst tillstånd, samt slutligen - vilket tillstånd det hanterade systemet uppnår när det utsätts för en viss operation.The operating support information model indicates which permissions the managed system can accept (permissions of interest from an operating aid point of view), - which operations can be targeted at the managed system with, which operations can be directed at a managed system in a certain condition, and finally - what condition the managed system achieves when it subjected to a certain operation.

Med en bestämbar specifikation av driftstödinformationsmode1- len avses här att dessa definitioner skall kunna uttryckas i ett maskintolkningsbart språk, ledande till att ovannämnda egenska- per kan bestämmas från specifikationen.With a definable specification of operational support information mode1- This means that these definitions can be expressed in one machine-interpretable language, leading to the above-mentioned per can be determined from the specification.

Blockschemat i fig. 3 visar de grundläggande konstruktions- blocken hos arkitekturen för driftstödfunktionen.The block diagram in Fig. 3 shows the basic construction blocks of the architecture for the operational support function.

I det här med 40 betecknade driftstödsystemet ingår den generella driftstödhanteraren 42 med ett användargränssnitt 44.This 40-unit operating support system includes it general operating support manager 42 with a user interface 44.

I detta gränssnitt kan alla styrda objekt hos det hanterade systemet inspekteras och modifieras.In this interface, all controlled objects of the managed the system is inspected and modified.

DCF-Data Communication Function 46, som även berörts in- ledningsvis, är en protokollimplementering, som bär ett drift- stödprotokoll såsom CMIP eller liknande. Denna kommunicerings- funktion utgör ej del av uppfinningen.DCF-Data Communication Function 46, which was also management, is a protocol implementation that carries an operational support protocols such as CMIP or similar. This communication function does not form part of the invention.

I det med 48 betecknade hanterade systemet ingår en generell agent 50, som terminerar driftstödprotokollet.The managed system denoted by 48 includes a general one agent 50, which terminates the operating support protocol.

Ett antal resursagenter 52 är representanter för klasserna av styrda objekt i det hanterade systemet. För varje klass av styrda objekt finns det en resursagent. Den för klassen av styrda objekt unika termineringen av driftstödprotokollet termi- neras i resursagenten.A number of resource agents 52 are representatives of the classes of controlled objects in the managed system. For each class of controlled objects, there is a resource agent. It leads the class off controlled objects unique termination of the operating support protocol termi- neras in the resource agent.

MIM-server 54, som likaledes berörts ovan, är i princip en resursagent för klassen MIM-server av styrda objekt. MIM-server är leverantör av representationen av den verkliga driftstödsin- .mr -,f_| CD (T1 çn 14 formationsmodellen av det hanterade systemet.MIM server 54, which is also discussed above, is basically one resource agent for the MIM server class of controlled objects. MIM server is the supplier of the representation of the actual operating aid .mr -, f_ | CD (T1 çn 14 the formation model of the managed system.

Databashanteringsfunktionen 56 (DBMS - Data Base Management System) är en objektorienterad databasserver. Den kan lagra, accessa och uppdatera objektstrukturerat persistent data.Database management function 56 (DBMS - Data Base Management System) is an object-oriented database server. It can store, access and update object-structured persistent data.

Hjälpgränssnittet 58 för styrda objekt (MOSI - Managed Object Service Interface) är ett generellt gränssnitt, som tillhand- hålls av alla resursagenter. Operationerna i detta gränssnitt är skapa, radera, skriv, läs och metod. Operationer i MOSI är alltid riktade mot en viss instans av en viss klass av styrda objekt.Managed Object Assistant Interface 58 (MOSI) Service Interface) is a general interface, which provides held by all resource agents. The operations in this interface are create, delete, write, read and method. Operations in MOSI are always directed at a particular instance of a particular class of governed object.

Datahanteringsgränssnittet 60 (DMI - Data Managing Interface) är gränssnitt mot DBMS. Det har operationer för skapande, rade- ring, läsning och uppdatering av objektstrukturerat persistent data.Data Management Interface 60 (DMI - Data Managing Interface) is an interface to DBMS. It has operations for creation, eradication call, reading and updating object-structured persistent data.

MOSI-gränssnittets specifikation ges nedan: #ifndef COOAMOSIBASE_flH afldef ine cooAMosIBAsE_m¶ /* $Id: CooaMosiBase.hh,v 1.6 1992/12/01 07:34:52 euassg $*/ #include class Delosßuffer; class DICOS_DbTransaction; enum CooaGetMode { Cooa_getSpecified=0, Cooa_getFirst=l, Cooa_getNext=2 }; typedef unsigned int CooaAttributeID; typedef unsigned int CooaActionID; typedef unsigned int CooaMoC1ass; typedef DelosBuffer CooaAccessControl; 15 enum CooaResultValue { Cooa_accessDenied=2, Cooa_noSuchAttribute=5, Cooa_inva1idAttributeValue=6, Coøa_noSuchAction=9, Cooa_processingFailure=10, Cooa_poSuchArgument=14, Cooa_ínvalidArgumentValue=15, Cooa_missingAttributeValue=18, Cooa_classInstanceConflict=l9, Cooa_mistypedOperation=21, Cooa_invalid0perator=24, Cooa_invalíd0peration=25, Cooa_notReplacable=1000, Cooa_noDefault=1001, Cooa_notAdded=1002, Cooa_notRemoved=1003, Cooa_false=1004, Cooa_inva1idCompareMode=1005, Cooa_noIteration=1006, Cooa_noMoreAttributes=1007, Cooa_ok=1008, Cooa_notReadable=1009, Cooa_interfaceViolation=10l0, }í enum CooaSetMode { Cooa_replace=0, Cooa_toDefault=1, Cooa_addMember=2, Cooa_removeMember=3, Cooa_initiate=4 }; enum CooaCompareMode { gm ID A (fl 04 3» G1 Cm 16 Cooa_equa1=0, Cooa_greater0rEqual=1, Cooa_less0rEqual=2, Cooa_present=3, Cooa_subset0f=4, Cooa_superset0f=5, Cooa_nonNullSetIntersection=6, Cooa_initialString=7, Cooa_anyString=8, Cooa_finalString=9 }i enum Cooa0penMode { Cooa_create=0, Cooa_delete=1, Cooa_update=2, Cooa_read=3 }i class CooaMosiBase : public CooaMosiVersion { public: virtual unsigned int Cooa_version () const { return 2000; }; virtual void get (CooaGetMode mode, CooaAttríbuteID& attributeNumber, DelosBuffer& attributevalue, CooaAccessControl& access, CooaResultValue& result, DelosBuffer& errorInformation)=0;// pure virtual virtual void set (CooaSetMode mode, CooaAttributeID attributeNumber, DelosBuffer& attributevalue, CooaAccessControl& access, CooaResultValue& result, DelosBuffer& errorInformation)=0;// pure virtual virtual void action (DelosBuffer& argument, 478 456 17 CooaActionID actionNumber, DelosBuffer& actionResult, CooaAccessControl& access, CooaResu1tValue& result, De1osBuffer& errorInformation)=0;// pure virtual virtual void compare (CooaCompareMode mode, CooaAttributeID attributeNumber, DelosBuffer& attributevalue, CooaAccessControl& access, CooaResultValue& result, DelosBuffer& errorInformation)=0;// pure virtual virtual void mode (CooaOpenMode openMode, CooaMoClass moClass, CooaAccessControl& access, CooaResultValue& result, DelosBuffer& errorInformation)=0;// pure virtual virtual CooaAttributeID getPrimaryKey(CooaResultValue& result) virtual CooaMosíBase* create (De1osBuffer& primaryKey, virtual DICOS_DbTransaction& trans, CooaMoClass moClass, CooaAccessControl& access, CooaResultValue& result, DelosBuffer& errorInformation)= 0; // pure virtual void getCounter (CooaAttríbuteID& attributeNumber, virtual }í #endif void*& counterøbject, CooaAccessControl& access, CooaResu1tValue& result, DelosBuffer& errorlnformation) = 0; // pure .fis -~J (IL) .ha Om (_"j\ 18 Den generella objekthanteraren 42 känner till gränssnittet för MIM-server. Den läser data från MIM-server och fastställer vilka klasser av styrda objekt som finns i det hanterade syste- met.The MOSI interface specification is given below: #ifndef COOAMOSIBASE_ fl H a fl def ine cooAMosIBAsE_m¶ / * $ Id: CooaMosiBase.hh, v 1.6 1992/12/01 07:34:52 euassg $ * / #include class Delosßuffer; class DICOS_DbTransaction; enum CooaGetMode { Cooa_getSpecified = 0, Cooa_getFirst = l, Cooa_getNext = 2 }; typedef unsigned int CooaAttributeID; typedef unsigned int CooaActionID; typedef unsigned int CooaMoC1ass; typedef DelosBuffer CooaAccessControl; 15 enum CooaResultValue { Cooa_accessDenied = 2, Cooa_noSuchAttribute = 5, Cooa_inva1idAttributeValue = 6, Coøa_noSuchAction = 9, Cooa_processingFailure = 10, Cooa_poSuchArgument = 14, Cooa_invalidArgumentValue = 15, Cooa_missingAttributeValue = 18, Cooa_classInstanceConflict = l9, Cooa_mistypedOperation = 21, Cooa_invalid0perator = 24, Cooa_invalíd0peration = 25, Cooa_notReplacable = 1000, Cooa_noDefault = 1001, Cooa_notAdded = 1002, Cooa_notRemoved = 1003, Cooa_false = 1004, Cooa_inva1idCompareMode = 1005, Cooa_noIteration = 1006, Cooa_noMoreAttributes = 1007, Cooa_ok = 1008, Cooa_notReadable = 1009, Cooa_interfaceViolation = 10l0, } í enum CooaSetMode { Cooa_replace = 0, Cooa_toDefault = 1, Cooa_addMember = 2, Cooa_removeMember = 3, Cooa_initiate = 4 }; enum CooaCompareMode { gm ID A (fl 04 3 » G1 Cm 16 Cooa_equa1 = 0, Cooa_greater0rEqual = 1, Cooa_less0rEqual = 2, Cooa_present = 3, Cooa_subset0f = 4, Cooa_superset0f = 5, Cooa_nonNullSetIntersection = 6, Cooa_initialString = 7, Cooa_anyString = 8, Cooa_finalString = 9 }in enum Cooa0penMode { Cooa_create = 0, Cooa_delete = 1, Cooa_update = 2, Cooa_read = 3 }in class CooaMosiBase: public CooaMosiVersion { public: virtual unsigned int Cooa_version () const {return 2000; }; virtual void get (CooaGetMode mode, CooaAttributeID & attributeNumber, DelosBuffer & attribute value, CooaAccessControl & access, CooaResultValue & result, DelosBuffer & errorInformation) = 0; // pure virtual virtual void set (CooaSetMode mode, CooaAttributeID attributeNumber, DelosBuffer & attribute value, CooaAccessControl & access, CooaResultValue & result, DelosBuffer & errorInformation) = 0; // pure virtual virtual void action (DelosBuffer & argument, 478 456 17 CooaActionID actionNumber, DelosBuffer & actionResult, CooaAccessControl & access, CooaResu1tValue & result, De1osBuffer & errorInformation) = 0; // pure virtual virtual void compare (CooaCompareMode mode, CooaAttributeID attributeNumber, DelosBuffer & attribute value, CooaAccessControl & access, CooaResultValue & result, DelosBuffer & errorInformation) = 0; // pure virtual virtual void mode (CooaOpenMode openMode, CooaMoClass moClass, CooaAccessControl & access, CooaResultValue & result, DelosBuffer & errorInformation) = 0; // pure virtual virtual CooaAttributeID getPrimaryKey (CooaResultValue & result) virtual CooaMosíBase * create (De1osBuffer & primaryKey, virtual DICOS_DbTransaction & trans, CooaMoClass moClass, CooaAccessControl & access, CooaResultValue & result, DelosBuffer & errorInformation) = 0; // pure virtual void getCounter (CooaAttríbuteID & attributeNumber, virtual } í #endif void * & counter object, CooaAccessControl & access, CooaResu1tValue & result, DelosBuffer & errorlnformation) = 0; // pure .fart - ~ J (IL) .have If (_ "j \ 18 The general object manager 42 knows the interface for MIM server. It reads data from MIM server and determines which classes of controlled objects exist in the managed system met.

I användargränssnittet 44 kan t.ex. begäran framställas att den generella objekthanteraren visar alla instanser av en viss klass av styrda objekt. Den generella objekthanteraren kan läsa definitionen av den utvalda klassen från MIM-server 54. Den känner till hur denna klass accessas via DCF till den generella agenten. Den vet även hur data från den generella agenten skall tolkas.In the user interface 44, e.g. request is made that the general object manager displays all instances of a particular class of controlled objects. The general object manager can read the definition of the selected class from MIM server 54. It know how this class is accessed via DCF to the general agents. It also knows how data from the general agent should be interpreted.

Med hänvisning till fig. 4 består resursagenten av tre delar, nämligen en MOSI-underagent 61, dataobjektlogik 62 (DOL - Data Objekt Logic), samt komplementär logik 64 (CL - Complementary Logic). Det tillhandahåller vidare det yttre gränssnittet 58, MOSI, och har har två inre gränssnitt, nämligen ett dataobjekt- gränssnitt 66 (DOI - Data Object Interface) och ett komplemen- tär-logik-gränssnitt 68 (CLI - Complementary Logic Interface).Referring to Fig. 4, the resource agent consists of three parts, namely, a MOSI subagent 61, data object logic 62 (DOL - Data Object Logic), and complementary logic 64 (CL - Complementary Logic). It further provides the external interface 58, MOSI, and has two internal interfaces, namely a data object interface 66 (DOI - Data Object Interface) and a complementary tar-logic interface 68 (CLI - Complementary Logic Interface).

Här skall nu en närmare, generell redogörelse ges för den med hänvisning till fig. 1 beskrivna principen att dela upp drift- stödsystemet i en generisk driftstödhanterare och en representa- tion av modellen av det hanterade systemet. Denna uppdelning benämns även nedan för referensensändamål separationsmodell.Here, a more detailed, general account will now be given of it Referring to Fig. 1, the principle of dividing the operating the support system of a generic operational support manager and a representative tion of the model of the managed system. This division also referred to below for reference purposes separation model.

För driftstöd av resurser i ett system måste det finnas vetskap om vad som skall erhålla driftstöd och hur det skall utföras. Härför behövs det tre huvudfunktioner, nämligen en styrande del av driftstödsystemet, nedan för enkelhetens skull i föreliggande sammanhang benämnd "styrande driftstödhanterare", en resursrepresentation, samt resursen. Figur 5 beskriver närma- re relationerna mellan de tre funktionerna. Ett problem är att ge den styrande driftstödhanteraren en generell möjlighet att hantera en särskild resurs. Det är därför nödvändigt att imple- mentera ett ramverk som medger konstruktion av tillämpningar, som kan hantera resurser utan att känna till den inre strukturen hos en resurs och dess möjligheter. Närmare bestämt skall nya resurser kunna tillföras och gamla skall kunna avvecklas eller ändras utan att påverka den styrande hanteraren.For operational support of resources in a system, there must be knowledge of what is to receive operating aid and how it is to be performed. This requires three main functions, namely one governing part of the operational support system, below for the sake of simplicity in hereinafter referred to as "governing operations support manager", a resource representation, as well as the resource. Figure 5 describes the re the relationships between the three functions. One problem is that give the controlling operational support manager a general opportunity to manage a particular resource. It is therefore necessary to implement develop a framework that allows the design of applications, who can manage resources without knowing the internal structure of a resource and its capabilities. Specifically, new ones resources can be added and old ones can be phased out or changes without affecting the controlling handler.

Ett sådant ramverk kan tillämpas på varje domän, där det existerar en relation mellan styrande driftstödhanterare och 479 456 19 hanterat system.Such a framework can be applied to any domain, where it there is a relationship between governing operational support managers and 479 456 19 managed system.

Det är väsentligt att ange att resursrepresentationen alltid uttrycks som angivelser på typnivå. Detta innebär att alla instanser av en viss typ delar på samma resursrepresentation. I fig. 6 ser man att enheterna T1-T4 på typnivå existerar på egen hand och att de kan delas mellan enheterna Il-I4 på instansni- vån. I ett visst exempel kan schemat enligt fig. 7 gälla. Typen abonnentnummer håller information, som beskriver hur instanser skall tolkas (exempelvis formatet hos ett telefonnummer och vilket slag av datastruktur, som används för att hålla tele- fonnumret).It is essential to state that resource representation always expressed as type-level indications. This means that everyone instances of a certain type share the same resource representation. IN Fig. 6 shows that the units T1-T4 at type level exist on their own hand and that they can be shared between units II-I4 at the floor. In a particular example, the scheme of Fig. 7 may apply. Types subscriber number holds information, which describes how instances to be interpreted (for example, the format of a telephone number and the type of data structure used to maintain telecommunications fonnumret).

Denna struktureringsteknik medger användning av en generell driftstödhanterare. Om schemat i fig. 7 gäller för ett system S1 och schemat i fig. 8 gäller för ett system S2 kan samma generel- la driftstödhanterare användas för driftstöd av både systemet S1 och systemet S2.This structuring technique allows the use of a general operational support manager. If the diagram in Fig. 7 applies to a system S1 and the diagram in Fig. 8 applies to a system S2, the same general let operating support managers be used for operating support of both system S1 and system S2.

Driftstödhanterarens vy av de två systemen visas i fig. 9.The operational support manager's view of the two systems is shown in Fig. 9.

Det är samma generella driftstödhanterare som används och den tolkar modellrepresentationerna i system S1 och system S2.It is the same general operating support manager that is used and it interprets the model representations in system S1 and system S2.

Systemens S1 och S2 driftsstödinformationsmodel1 av abonnent- nummer är olika.Systems S1 and S2 operating support information model1 of subscriber numbers are different.

I fig. 9 riktar hanteraren sina operationer mot resurser som skall hanteras i system S1 och system S2. För att få rätt syntax och dataformat tolkar hanteraren modellrepresentationerna R1 och R2. Från en användares synpunkt är driftstödramverket detsamma, dvs. samma koncept, metaforer och verktyg kan användas, var- igenom medel erhålles för effektiv och lätt hantering av resur- ser oberoende av deras verkliga implementation.In Fig. 9, the operator directs his operations toward resources such as shall be handled in system S1 and system S2. To get the right syntax and data format, the handler interprets the model representations R1 and R2. From a user's point of view, the operational support framework is the same, i.e. the same concept, metaphors and tools can be used, funds are obtained for efficient and easy management of resources. looks independent of their actual implementation.

Vad som eftersträvas är nu ett sätt att implementera ett ram- verk, som kan användas för konstruktion av generella driftstöd- hanterare, vilka hanterar fysiska och/eller logiska resurser.What is being sought is now a way to implement a framework plants, which can be used for the construction of general operating managers, who manage physical and / or logical resources.

Ramverket utförs genom en rigorös och formell separering av resursrepresentationen (modellen) och den verkliga resursen.The framework is carried out through a rigorous and formal separation of the resource representation (model) and the actual resource.

Resursrepresentationen tolkas av en mjukvaruenhet benämnd sty- rande driftstödhanterare.The resource representation is interpreted by a software unit called operating support managers.

Driftstödhanterarenheten skall inte behöva ha någon särskild resursinformation i förväg, dvs. innan den har börjat verka.The operational support manager unit shall not need to have any special resource information in advance, ie. before it has started to work.

Detta betyder att hanterarenheten är i stånd att anpassas till varje möjlig resursrepresentation, som uttrycks på sådant sätt 4%- “flfl Cl.) 01 Ch 20 att den är tolkningsbar av hanteraren. Huvudfördelen är att det är möjligt att införa nya typer av resurser utan uppdatering av hanteraren.This means that the handling unit is able to adapt to any possible resource representation, expressed in such a way 4% - “Fl fl Cl.) 01 Ch 20 that it is interpretable by the handler. The main advantage is that it is possible to introduce new types of resources without updating the handler.

Som exempel kan man med en given viss resurs, såsom en abonnent, introducera nya möjligheter i abonnenten, och fort- farande vara i stånd att hantera både den nya och den gamla abonnentrepresentationen med samma hanterare.As an example, one can with a given certain resource, such as one subscriber, introduce new opportunities in the subscriber, and be able to handle both the new and the old the subscriber representation with the same manager.

Som ett annat exempel kan man vid implementering av en totalt ny typ av resurs introducera denna i hanterarsystemet och hante- ra den nya resursen med befintliga hanterare.As another example, when implementing a total introduce a new type of resource into the management system and ra the new resource with existing managers.

Här skall nu en närmare redogörelse för de i fig. 5 åskådlig- gjorda gränssnitten ges.Here, a more detailed account of the illustrations shown in Fig. 5 made interfaces are given.

Accessgränssnitt för modell.Access interface for model.

Detta gränssnitt används av den styrande driftstödhanteraren för att ansluta sig till en resursrepresentation och hämta information från den. Denna information används vid utförande av generella driftstödoperationer mot en resurs. Ett exempel fram- går av fig. 10. Genom tydande av resursrepresentationen kan hanteraren exempelvis utföra operationen i fig. 11 på abonnent- nummerinstansen Il och vara säker på att syntax och semantik gäller med avseende på modellen.This interface is used by the controlling operating support manager to join a resource representation and download information from it. This information is used in the execution of general operational support operations against a resource. An example goes from Fig. 10. By clarifying the resource representation can the handler performs, for example, the operation of Fig. 11 on the subscriber number instance II and be sure of syntax and semantics applies with respect to the model.

Det är väsentligt att se att samma hanterare är i stånd att hantera den uppdatering/ändring av informationen i resursrepre- sentationen i fig. 10, som visas i fig. 12, utan att behöva omkompileras eller omkonfigureras.It is essential to see that the same handler is able to handle the updating / modification of the information in the resource the presentation in Fig. 10, shown in Fig. 12, without need recompiled or reconfigured.

I inget av fallen skulle den i fig. 13 visade operationen behöva sändas till resursen. Felaktiga operationer kommer alltså inte att alls sändas till resursen.In none of the cases would the operation shown in Fig. 13 need to be sent to the resource. Incorrect operations will thus occur not to be sent to the resource at all.

Det ifrågavarande gränssnittet har följande operationer. 1 - anslut_till_representation 2 - tolka_representation Accessgränssnitt för resurs.The interface in question has the following operations. 1 - connect_to_representation 2 - tolka_representation Resource access interface.

Detta gränssnitt används vid utförande av hanteringsopera- tioner mot den verkliga resursen. Operationer i detta gränssnitt är ofta implementationsberoende.This interface is used to perform management operations against the real resource. Operations in this interface is often implementation dependent.

Operationer: 1 - utför_operation (öppna/läs/skriv/sök etc.) 2 - transformera_händelse.Operations: 1 - perform_operation (open / read / write / search etc.) 2 - transform_event.

Informationsgränssnitt för driftstödförmåga. 47Û 456 21 Detta gränssnitt anger vilka möjligheter en viss hanterare kan använda vid driftstödhantering av resursen. Detta gränssnitt kan begränsa det som hanteraren kan göra i accessgränssnittet för modellrepresentation.Information interface for operational support capacity. 47Û 456 21 This interface specifies the capabilities of a particular handler can use in operational support management of the resource. This interface can limit what the manager can do in the access interface for model representation.

Operationer: 1 - kontrollera_access 2 - begränsa_access Informationsgränssnitt för resursförmåga.Operations: 1 - check_access 2 - restrict_access Information interface for resource capacity.

Detta gränssnitt anger, vilken förmåga hos resursen som kommer att exporteras och visas i dess resursrepresentation. Vissa former av förmåga i den verkliga resursen kan multiplexas och anges som en enda förmåga inom resursrepresentationen.This interface indicates the capability of the resource to come to be exported and displayed in its resource representation. Some forms of ability in the real resource can be multiplexed and is stated as a single ability within the resource representation.

Operationer: 1 - export_möjlighet 2 - multiplex_möjlighet.Operations: 1 - export_possibility 2 - multiplex_possibility.

Den styrande driftstödhanteraren.The controlling operating support manager.

En styrande driftstödhanterare i det ifrågavarande ramverket är en mjukvaruenhet i stånd att tolka modellrepresentationer uttryckta på ett maskintolkningsbart sätt. Dessa representatio- ner anger protokollet för möjlig samverkan mellan driftstöd- hanterare och den hanterade resursen. Representationen anger även datastrukturer, som används för att representera ett kon- cept i den hanterade resursen. Många styrande driftstödhanterare kan använda en representation och en styrande driftstödhanterare kan använda många representationer.A governing operational support manager in the framework in question is a software unit capable of interpreting model representations expressed in a machine-interpretable way. These representations indicates the protocol for possible collaboration between operating manager and the managed resource. The representation indicates also data structures, which are used to represent a con- cept in the managed resource. Many governing operations support managers can use a representation and a governing operations support manager can use many representations.

Representationen.The representation.

En representation av en resurs är i det föreliggande samman- hanget en vy av någon eller alla aspekter "inom" en resurs. Det kan finnas många vyer av en resurs. I representationen är in- formation strukturerad på sådant sätt att det är möjligt att tolka den för att göra transformationer till andra representa- tioner, som är lämpligare för exempelvis samverkan med människa.A representation of a resource is in the present context hung a view of any or all aspects "within" a resource. The there can be many views of a resource. The representation includes formation structured in such a way that it is possible to interpret it to make transformations into other which are more suitable for, for example, human interaction.

Representationen kan användas för att mata mer eller mindre intelligent mjukvara med nödvändig information för utförande av driftstödoperationer.The representation can be used to feed more or less intelligent software with the necessary information to perform operational support operations.

Huvudfördelen med den ovan beskrivna separationsmodellen är att den tillhandahåller medel för införing och uppdatering av resurser och tjänster inom en hanteringsdomän utan att påverka de enheter som hanterar resurserna och tjänsterna. Vidare kan de .Pn- N11 C23 UI Ch 22 enheter, som hanterar den verkliga resursen ersättas/uppdateras utan att påverka de enheter som hanteras. När ny teknologi blir tillgänglig kan den sålunda introduceras vid en tidpunkt som är lämplig för hanteringsdomänen.The main advantage of the separation model described above is that it provides means for the introduction and updating of resources and services within a management domain without affecting the units that manage the resources and services. Furthermore, they can .Pn- N11 C23 UI Ch 22 units, which handle the actual resource are replaced / updated without affecting the devices being handled. When new technology becomes available, it can thus be introduced at a time which is suitable for the management domain.

Gammal och ny teknologi kan samexistera i hanteringsdomänen.Old and new technology can coexist in the management domain.

I exempelvis ett telekomnät kan utrustning (resursenheter och driftstödenheter) införas i en eller flera diskreta aktiviteter.In a telecom network, for example, equipment (resource units and operational support units) are introduced in one or more discrete activities.

I fig. 14 visas en hanteringsdomän, som består av två system med olika versioner av enheterna. Versionerna skiljer sig inom varje system och mellan de båda systemen. Härvid gäller: 1 - "Gamla" driftstödhanterare av typ 1 kan hantera resurser av typerna 1, 100 och 200. 2 - "Nya" hanterare av typ 100 kan hantera resurser av typerna 1, 100 och 200. 3 - Det finns inga hanterare som utvecklats till typ 200. 4 - Resurser av alla typer hanteras av hanterare av alla typer.Fig. 14 shows a management domain, which consists of two systems with different versions of the devices. The versions differ within each system and between the two systems. In this case: 1 - "Old" type 1 operational support managers can manage resources of types 1, 100 and 200. 2 - "New" type 100 managers can manage resources of types 1, 100 and 200. 3 - There are no handlers developed for type 200. 4 - Resources of all types are managed by managers of all types.

I fig. 14 har man en arbetande domän där teknologisk ut- veckling skett på ett okoordinerat sätt. Vad vi ser är att i varje skikt (horisontellt) modifikationer har gjorts utan att påverka enheten från driftstödhanterarens synpunkt (vertikalt).In Fig. 14, there is a working domain where technological development took place in an uncoordinated manner. What we see is that in each layer (horizontal) modifications have been made without affect the unit from the point of view of the operating support manager (vertically).

Här skall nu redogöras för hur den ovan beskrivna separa- tionsmodellen används vid konstruktion av styrande driftstöden- heter.Here it will now be explained how the separation described above model is used in the design of governing operating called.

Den styrande driftstödhanteraren som svarar för driftstöd- operationerna mot en resurs erhåller inom separationsmodell- ramverket den nödvändiga vetskapen från en modellrepresentation, som innehåller modellinformation om en resurs.The governing operations support manager responsible for operations against a resource receive within the separation model the framework the necessary knowledge from a model representation, which contains model information about a resource.

Driftstödhanteraren är byggd på det ramverk som ges av separationsmodellen, varvid den generella driftstödhanteraren i detta ramverk konstrueras enligt fig. 15.The operational support manager is built on the framework provided by the separation model, whereby the general operating support manager in this framework is constructed according to Fig. 15.

Konstruktionen innehåller i ett driftstödhanterarskikt 80 ett antal enheter, vilkas benämning framgår av figuren, och i ett modellskikt 82 en resursrepresentation.The structure contains in an operating support handler layer 80 a number of units, the name of which appears from the figure, and in one model layer 82 a resource representation.

Enheten för anpassning av yttre användargränssnitt, vid 80, används vid anpassning av driftstödhanteraren till en yttre enhet. Exempel härpå är: - Fönstersystem. Detta sätter en mänsklig användare i stånd att samverka med resurserna genom manipulering av återgivnings- 23 bara representationer, såsom formulär, menyer och grafiska representationer.External user interface customization device, at 80, is used when adapting the operating support manager to an external unit. Examples of this are: - Window system. This enables a human user to interact with the resources by manipulating the reproduction 23 only representations, such as forms, menus and graphics representations.

- Andra datorer/datasystem.- Other computers / computer systems.

'- Databaser.'- Databases.

- En enhet i själva driftstöddomänen. Driftstödhanteraren kan med andra ord användas som en styrande och beslutsfattande enhet.- A unit in the operating support domain itself. The Operational Support Manager can in other words used as a governing and decision-making unit.

Som exempel på en representation, med vilken en mänsklig an- vändare samverkar, kan man betrakta fig. 16, som visar hur ett fönster är relaterat till en driftstödsinformationsmodell enligt fig. 10.As an example of a representation, with which a human turners interact, one can look at Fig. 16, which shows how one window is related to an operational support information model according to Fig. 10.

Denna information används även vid verifiering av att in- signalen är korrekt enligt modellen. I exemplet ovan skulle an- vändaren ej vara i stånd att införa ett telefonnummer, som ej är anpassat till resursrepresentationen i fig. 10. Driftsstödhante- raren kan använda vetskapen till att leda användaren eller före- slå vad som skall göras. Den enligt fig. 10 ogiltiga användar- samverkan, som visas i fig. 12 skulle ej kunna transformeras till driftstödoperationer och sändas till resursen. Det i fig. 17 beskrivna uppförandet utgör resultat av modelltolkningsför- mågan hos en driftstödhanterare, vilken använder separationsmo- dellramverket.This information is also used to verify that the the signal is correct according to the model. In the example above, the turner may not be able to enter a telephone number which is not adapted to the resource representation in Fig. 10. Operational support the user can use the knowledge to guide the user or beat what needs to be done. The invalid user according to Fig. 10 the interaction shown in Fig. 12 could not be transformed to operational support operations and sent to the resource. The device shown in FIG. The behavior described in Figure 17 is the result of a model interpretation the ability of an operations support manager, which uses separation modes sub-framework.

Den verkliga hanterade resursen (mySubDir) är fortfarande i giltigt tillstånd och inget försök har gjorts att utföra en ogiltig operation.The actual managed resource (mySubDir) is still in valid permit and no attempt has been made to perform one invalid operation.

Med den typ av driftstödhanterare, som beskrivs här, delege- ras ett antal kontroller till användaren av modellen, dvs den generella driftstödhanteraren, i stället för att utföras av själva resursen. Detta betyder att en resurs är i stånd att uppfylla önskemål i olika användarfall. Användarfallen kommer troligen att vara olika tidsmässigt. I ett traditionellt utför- ande skulle man behöva förutse möjliga framtida användarfall, medan i det föreliggande ramverket man endast behöver göra en annan modellrepresentation.With the type of operational support manager described here, delegate a number of controls are passed to the user of the model, i.e. the general operating support manager, instead of being performed by the resource itself. This means that a resource is capable of fulfill wishes in different user cases. The user cases are coming likely to be different in time. In a traditional embodiment one would need to anticipate possible future user cases, while in the present framework one only needs to do one other model representation.

Som exempel på ett mera traditionellt sätt skulle en "abon- nentnummer-resurs" kunna implementera de i fig. 10 beskrivna reglerna som C++-angivelser i den resursen representerande koden. Resursens användning vore då begränsad till ett samman- hang där telefonnummer endast kunde börja med 727. .5-7. >/Ü *mJO 24 Den inre representationsenheten 86 transformerar modell- representationen till en representation, som är lämplig för användning av en styrande driftstödhanterare. Abstrakta data- strukturer etc. i modellen mappas med andra ord till datastruk- turer, som kan användas vid driftstödhanterarens bearbetning.As an example of a more traditional way, a "subscriber be able to implement those described in Fig. 10 the rules as C ++ statements in that resource representative the code. The use of the resource would then be limited to a hang where phone numbers could only start with 727. .5-7. > / Ü * mJO 24 The internal representation unit 86 transforms the model the representation to a representation, which is suitable for use of a controlling operations support manager. Abstract data structures etc. in the model are mapped in other words to data structures tours, which can be used in the processing of the operational support manager.

Den inre representationsenheten skapar en struktur, som används för att lagra resursrepresentationerna. Det finns åt- minstone en sådan struktur för varje driftstödhanterardomän.The internal representation unit creates a structure, which used to store the resource representations. There are at least one such structure for each operational support manager domain.

Inledningsvis är strukturen tom, men fylls senare med resurs- representationer. Strukturen kan skapas på ett antal sätt (pri- märminne, objektdatabas, etc).Initially, the structure is empty, but is later filled with resources. representations. The structure can be created in a number of ways (pri- memory, object database, etc).

I fig. 18 kan man se att resursrepresentationerna R1-R5 är organiserade i en datastruktur. Denna struktur används av den styrande driftstödhanteraren för att få åtkomst till resurs- representationerna. som synes har även resursrepresentationerna relationer.In Fig. 18 it can be seen that the resource representations R1-R5 are organized in a data structure. This structure is used by it governing operational support manager to access the resource representations. as can be seen, the resource representations also have relationships.

Sådana relationer utgör del av modellen för driftstödhanterar- domänen (ett abonnentkatalognummer har exempelvis en relation till LIC).Such relationships form part of the operational support management model. the domain (for example, a subscriber directory number has a relationship to LIC).

Den generella driftstödhanterarens interna representation av driftstödinformationsmodellen används av driftstödhanteraren för att vidmakthålla det hanterade systemets konsistens och för att sluta sig till det hanterade systemets tillstånd efter det att vissa operationer utförts. Operationerna kan exempelvis leda till en konsistensöverträdelse, men den kommer att upptäckas innan operationerna utövas på det hanterade systemet.Internal Representation of the General Operational Assistance Officer by the operational support information model is used by the operational support manager for to maintain the consistency of the managed system and to adhere to the state of the managed system after that certain operations have been performed. The operations can, for example, lead to a consistency violation, but it will be detected before the operations are performed on the managed system.

Kännedomen, som erhålls genom tolkning av modellen, kan användas av driftstödhanteraren på olika sätt, såsom: . - automatiskt lösning av konsistensöverträdelserna och skapande av en uppsättning driftstödsoperationer, som ej strider mot modellen, - ledning av en interaktiv användare till rätt uppsättning operationer, - utföring av "vad om" analyser.The knowledge obtained by interpreting the model can be used by the operational support manager in various ways, such as: . automatic resolution of inconsistencies and creation of a set of non-conflicting operational support operations against the model, guidance of an interactive user to the right set operations, - performing "what if" analyzes.

Den generella driftstödhanterarens logiska enhet 88 styr andra enheters aktivitet. Den fattar även beslut baserade på händelser, som rapporteras från andra enheter. Händelser kan även rapporteras från enheter utanför hanteraren, vilkas hän- delser alltid transformeras till representationer och struk- 47Q ffšö 25 turer, som kan hanteras av hanteraren.The general operating aid manager's logic unit 88 controls activity of other entities. It also makes decisions based on events, which are reported from other entities. Events can also reported from units outside the handler, whose are always transformed into representations and structures 47Q ffšö 25 tours, which can be handled by the handler.

Den yttre representationsenheten 90 hanterar transformation av inre representationer i hanteraren till representationer, som kan leda till och förstås av en enhet, som är ansluten till enheten "anpassning av yttre användargränssnitt" vid 80. Exempel på en sådan representation är en struktur representerande ett fönster, som kan återges på en X-Windows-anordning.The external representation unit 90 handles transformation of internal representations in the handler to representations, which can lead to and be understood by a device, which is connected to the "external user interface customization" device at 80. Example on such a representation is a structure representing one windows, which can be displayed on an X-Windows device.

Enheten "Maskin" för driftstödoperationer, vid 94, skapar verkliga hanteringsoperationer, som skall vidareledas till en resurs i hanterarens domän. Operationen skapas som resultat av yttre eller inre (eller bådadera) samverkningar/manipulationer av en av driftstödhanterarens logiska enhet 88 styrd representa- tion. Ett fönster representerande ett formulär är exempelvis en representation, som styrs av hanteraren. Fönstret kan återge påverkningsalternativ för användaren. Ett ingrepp i fönstret kan resultera i aktiviteter i hanteraren. Vissa av aktiviteterna kan resultera i att en eller flera driftstödoperationer sänds till den hanterade resursen.The "Machine" unit for operational support operations, at 94, creates actual handling operations, which shall be forwarded to a resource in the manager's domain. The operation is created as a result of external or internal (or both) interactions / manipulations controlled by a representative of the operating unit's logic unit 88 tion. For example, a window representing a form is one representation, which is controlled by the manager. The window can reproduce impact options for the user. An intervention in the window can result in activities in the manager. Some of the activities can result in one or more operational support operations being sent to the managed resource.

Enheten accessgränssnitt för driftstödsystemdomänen, vid 96, svarar för sändning av hanteraroperationer till den hanterade enheten. Det ifrågavarande accessgränssnittet kan anpassas till olika driftstödprotokoll.The access interface system for the operating support system domain, at 96, is responsible for sending handler operations to the handler the device. The access interface in question can be adapted to different operating support protocols.

Enheten modelltolk vid 92 svarar för tolkning av de i model- len uttryckta resursrepresentationerna. Modelltolken läser resursrepresentationerna och tilldelar dem till den ovan be- skrivna enheten för intern representation.The model interpreter unit at 92 is responsible for interpreting the expressed resource representations. The model interpreter reads the resource representations and allocates them to the written unit for internal representation.

Modelltolken tolkar representationen av en resurs. Represen- tationen uttrycks i ett överenskommet format. Det är formatet av modellrepresentationen, som används.The model interpreter interprets the representation of a resource. Representative is expressed in an agreed format. It's the format of the model representation, which is used.

För att utföra en driftstödoperation, exempelvis för att ändra ett abonnentnummer genomförs följande moment: 1. En anslutning till driftstödsdomänen upprättas. 2. Användaren (förmodligen utanför enheten för yttre repre- sentation) adresserar den resurs som skall hanteras (exempelvis en abonnent). 3. Driftstödhanterarens logiska enhet kontrollerar via enheten för inre representation om det redan finns en inre representation av den för hantering avsedda resursen. 4. Om en sådan representation ej finns, beordrar driftstöd- .fën ~.,_'_| "Fre (N 7'"| O\ 26 hanterarens logiska enhet "maskinen" för driftstödoperationer att utföra driftstödoperationer via accessgränssnittet för driftstöddomänen för att hämta en resursrepresentation från det hanterade systemet. (annars fortsätter det hela med punkt 7 nedan). 5. Den hämtade resursrepresentationen överförs till enheten för inre representation, som transformerar den till ett för driftstödhanteraren lämpligt format. 6. Enheten för inre representation placerar representationen i en struktur, som representerar summan av resursrepresenta- tioner i driftstödhanteringsdomänen. 7. Om en sådan representation finns transformerar driftstöd- hanterarens logiska enhet den inre representationen till en lämplig yttre representation med användning av den yttre repre- sentationsenheten. 8. Den yttre representationen vidareleds till gränssnittan- passningen för yttre användare, där representationen kan an- vändas av användaren (genom manipulering av ett formulär, som visas som ett X fönster). 9. Den yttre användaren ändrar värdet på abonnentnummerattri- butet (användaren matar exempelvis in ett värde i ett därför avsett organ). 10. Modelltolken kontrollerar om det inmatade värdet strider mot något i resursrepresentationen eller i det sammanhang, där resursrepresentationen uppträder (detta innebär att ett antal driftstödhanteringsoperationer kan behöva utföras mot det hante- rade systemet.) 11. Om en överträdelse upptäcks underrättas användaren på ett lämpligt sätt (förslag, notifikation etc.).To perform an operational support operation, for example to To change a subscriber number, the following steps are performed: 1. A connection to the operating support domain is established. 2. The user (probably outside the external reproduction unit) sentation) addresses the resource to be managed (for example a subscriber). 3. The operational support manager's logical unit controls via the internal representation unit if there is already an internal one representation of the resource to be managed. 4. If such a representation does not exist, the operating aid .fën ~., _'_ | "Fri. (N 7 '"| O\ 26 the operator's logical unit "machine" for operational support operations to perform operational support operations via the access interface for the operating support domain to retrieve a resource representation from it handled the system. (otherwise it all continues with point 7 below). 5. The retrieved resource representation is transferred to the device for internal representation, which transforms it into a for the operating support manager in an appropriate format. The Internal Representation Unit places the representation in a structure, which represents the sum of the resource in the operational support management domain. 7. If such a representation exists, the operating aid the logical unit of the handler the internal representation of a appropriate external representation using the external representative the sending unit. 8. The external representation is forwarded to the interface suitable for external users, where the representation can be turned by the user (by manipulating a form, which displayed as an X window). 9. The remote user changes the value of the subscriber number butet (the user enters a value in a therefore, for example intended body). 10. The model interpreter checks if the entered value conflicts against something in the resource representation or in the context, where resource representation occurs (this means that a number operational support management operations may need to be performed against the system.) 11. If a violation is detected, the user is notified immediately appropriate way (proposal, notification, etc.).

Huvudfördelen med en hanterare som konstrueras på i fig. 15 angivet sätt och används i separationsmodellsammanhanget är att den kommer att vara i stånd att hantera resursenheter i en föränderlig omgivning utan behov av uppdatering av hanterarenhe- terna och därmed koordinerade resursenheter. Vid utveckling av hanterar- och resursenheter separat kan bästa möjliga teknik vidare användas.The main advantage of a handler constructed in Fig. 15 specified method and used in the separation model context is that it will be able to manage resource units in one changing environment without the need to update the manager and thus coordinated resource units. In the development of management and resource units separately know the best possible technology further used.

Här kommer nu en beskrivning att ges av en utföringsform, som avser hur modellrepresentationen i ovan beskrivna separationsmo- dell kan lagras i det hanterade systemet. Det tekniska problemet 27 är hur man alltid skall kunna hålla ett driftstödssytem med korrekt driftstödinformationsmodel1 avseende ett visst hanterat system, som kan ändras med tiden.Here, a description will now be given of an embodiment, which refers to how the model representation in the separation modes described above dell can be stored in the managed system. The technical problem 27 is how to always be able to keep an operating support system with correct operational support information model1 regarding a certain managed systems, which can change over time.

I fig. 19 visas ett enligt separationsmodellen modelldrivet driftstödsystem 100, som kan manipulera objekt i ett annat system. Driftstödsystemet kommunicerar med det hanterade syste- met 102 via en agent 104. För att kunna manipulera objekt 106 behöver driftstödsystemet information, som beskriver det hante- rade systemet. Frågan är hur hanteraren 108 i driftstödsystemet erhåller denna information.Fig. 19 shows a model driven according to the separation model operating support system 100, which can manipulate objects in another system. The operational support system communicates with the managed system. met 102 via an agent 104. To be able to manipulate object 106 the operational support system needs information, which describes the the system. The question is how the handler 108 in the operating support system receives this information.

Om driftstödsystemet kan fås att läsa driftstödinformation vid behov blir driftstödsystemet mera oberoende av det hanterade systemet. Om de enda beroendena mellan driftstödsystemet och det hanterade systemet är sättet på vilket driftstödsinformation struktureras, blir det möjligt att utveckla de tvâ systemen oberoende. För att lösa dessa problem införes ett nytt objekt i det hanterade systemet. Eftersom driftstödsystemet kan läsa data från varje hanterat system vid varje tidpunkt är det bästa stället att lagra data om det hanterade systemet i det hanterade systemet självt. Att använda detta nya slag av objekt skapar nya problem, såsom med avseende på hur de är strukturerade, och hur de skall installeras i systemet, och vid vilken tidpunkt etc.If the operating support system can be made to read operating support information if necessary, the operational support system becomes more independent of what is handled the system. About the only dependencies between the operational support system and it managed system is the way in which operational support information structured, it will be possible to develop the two systems Independent. To solve these problems, a new object is inserted in the managed system. Because the operating support system can read data from each managed system at any given time is the best instead of storing data about the managed system in the managed one the system itself. Using this new kind of object creates new ones problems, such as how they are structured, and how they must be installed in the system, and at what time, etc.

Att lagra information i ett hanterat system, som beskriver andra objekt i det hanterade systemet är ett sätt att låta driftstödsystemet bli i stånd att läsa sådan information vid varje tidpunkt. För att kunna använda ett gemensamt objekt för att beskriva alla slag av objekt krävs det emellertid att analys sker av vad slags information ett driftstödsystem behöver för att utföra sina uppgifter.To store information in a managed system, which describes other objects in the managed system are a way of sounding the operational support system will be able to read such information at any time. To be able to use a common object for To describe all kinds of objects, however, analysis is required is made of what kind of information an operational support system needs to perform their duties.

Vid en strukturering av alla objekt i ett hanterat system finner man att det är informationen som beskriver klasserna av styrda objekt, som behöver ingå i det nya objektet. Om man jämför t.ex. de två styrda objekt av olika klasser, som framgår av fig. 20, ser man att båda objekttyperna har attribut, rela- tioner och metoder. Vad som skiljer är namnen på attributen etc. och antalet attribut eller relationer eller metoder. Med an- vändning av denna information kan man utforma en mall, som beskriver styrda objekt i allmänhet. Denna mall ingår i det styrda objektet MIM-server, vilket berörts tidigare, och visas i .Pa ~.__] CD (51 (fjK 28 fig. 21. Genom användning av mallen kan man beskriva varje styrt objekt, som kan användas i det hanterade systemet. Om man in- stallerar ett MIM-server-objekt innehållande information som beskriver en objekttyp, som vi installerar samtidigt i det hanterade systemet, och driftstödsystemet kan tolka MIH-server- objekttypen, blir det möjligt för driftstödsystemet att hämta information om objekt i det hanterade systemet vid varje tid- punkt.When structuring all objects in a managed system one finds that it is the information that describes the classes of controlled objects, which need to be included in the new object. If compare e.g. the two controlled objects of different classes, as shown of Fig. 20, it can be seen that both object types have attributes, and methods. What differs are the names of the attributes etc. and the number of attributes or relationships or methods. With an- use of this information, one can design a template, which describes controlled objects in general. This template is part of it controlled object MIM server, which was touched on earlier, and displayed in .Pa ~ .__] CD (51 (fjK 28 Fig. 21. Using the template, one can describe each controlled objects, which can be used in the managed system. If you enter installs a MIM server object containing information such as describes an object type, which we install simultaneously in it managed system, and the operating support system can interpret the MIH server object type, it will be possible for the operating support system to retrieve information about objects in the managed system at each time point.

Begränsningen av vilken driftstödinformation, som MIM-server- objektet kan innehålla, beror bara på hur uttrycksfullt ett hanterat system kan specificeras, eftersom ifrågavarande styrda objekt automatiskt genereras och fylls med data som härrör från själva objektspecifíkationen.The limitation of which operating support information, which MIM server the object can contain, depends only on how expressive one managed system can be specified, since in question controlled objects are automatically generated and filled with data derived from the object specification itself.

Ett exempel på hur strukturen hos MIM-server-klassen skulle kunna se ut visas nedan. Exemplet är utfört så att det skall vara lätt läsbart, men skulle kunna specificeras i ett godtyck- ligt språk. Några av förkortningarna behöver en förklaring: - ADT (AbstractDataType) abstrakt datatyp; - DD (DataDomain) = datatyp; - PERSISTENT = skall lagras i databas.An example of how the structure of the MIM server class would be be able to look like is shown below. The example is designed so that it should be easy to read, but could be specified in an arbitrary language. Some of the abbreviations need an explanation: - ADT (AbstractDataType) abstract data type; - DD (DataDomain) = data type; - PERSISTENT = must be stored in database.

PERSISTENT ADT Him IS PRIMARY KEY myClassId; ATTRIBUTES myClassId: Integer; myClassName: String:="NoName"; myClassVersion: String:="1.0"; myAttributeList: AttributeArray; myActionList: ActionArray; myNoticationList: NotificationArray; myNameBindingList: NameBindingArray; END ADT Mim; Man finner att attributlistan (myAttributeList) specificeras som ett fält av attribut (AttributeArray). Fältet är i själva verket ett dynamiskt fält, vilket betyder att det inte har någon förutbestämd storlek, utan istället växer för varje element som adderas: TYPE AttributeArrayIS ARRAY OF Attribute 4-70 456 29 END TYPE; Fältet innehåller element vilkas namn är "Attribute", efter- som varje element i skaran kommer att beskriva egenskaper hos ett verkligt attribut i en M0-specifikation. Vid närmare under- sökning av attributspecifikationen finner man att det förekommer attribut såsom myName etc., vilka alla beskriver attributegen- skaper: ADT AttributeIS ATTRIBUTES myName: String:="NIL"; optional: Boolean.=False; myExternId: IntegerArray; myInternId: Integer:=0; myDD: DD; END ADT Attribute; TYPE IntegerArrayIS ARRAY OF Integer END TYPE; Vid betraktande av myDD finner man att det definieras som DD, dvs typ. Det förklaras vidare i nästa specifikation.PERSISTENT ADT Him IS PRIMARY KEY myClassId; ATTRIBUTES myClassId: Integer; myClassName: String: = "NoName"; myClassVersion: String: = "1.0"; myAttributeList: AttributeArray; myActionList: ActionArray; myNoticationList: NotificationArray; myNameBindingList: NameBindingArray; END ADT Mim; You will find that the attribute list (myAttributeList) is specified as a field of attributes (AttributeArray). The field is in itself the work a dynamic field, which means it has no one predetermined size, but instead grows for each element that add: TYPE AttributeArrayIS ARRAY OF Attribute 4-70 456 29 END TYPE; The field contains elements whose name is "Attribute", after- which each element in the crowd will describe the properties of a real attribute in an M0 specification. On closer examination search of the attribute specification you will find that it occurs attributes such as myName etc., all of which describe attribute properties creates: ADT AttributeIS ATTRIBUTES myName: String: = "NIL"; optional: Boolean. = False; myExternId: IntegerArray; myInternId: Integer: = 0; myDD: DD; END ADT Attribute; TYPE IntegerArrayIS ARRAY OF Integer END TYPE; When looking at myDD, one finds that it is defined as DD, ie typ. This is further explained in the next specification.

ADT DD IS ATTRIBUTES Which0ne: D WhichOne; myIntDD:' ItDD OPTIONAL myRealDD: RealDD OPTIONAL; myTextDD: TextDD OPTIONAL; myEnumDD: EnumDD OPTIONAL; myOctetDD: 0ctetDD OPTIONAL; myRangeDD: RangeDD OPTIONAL; myArrayDD: ArrayDD OPTIONAL; myStructDD: StructDD OPTIONAL; myRefDD: ReferenceDD OPTIONAL; myExtDD: ExternalDD OPTIONAL; END ADT DD; Eftersom ett attribut är av en typ såsom ett heltal, real, sträng, etc, är denna information väsentlig. Problemet är att ett attribut ej kan vara alla typer på en gång, utan bara en Jfr. il CJ -m.ADT DD IS ATTRIBUTES Which0ne: D WhichOne; myIntDD: 'ItDD OPTIONAL myRealDD: RealDD OPTIONAL; myTextDD: TextDD OPTIONAL; myEnumDD: EnumDD OPTIONAL; myOctetDD: 0ctetDD OPTIONAL; myRangeDD: RangeDD OPTIONAL; myArrayDD: ArrayDD OPTIONAL; myStructDD: StructDD OPTIONAL; myRefDD: ReferenceDD OPTIONAL; myExtDD: ExternalDD OPTIONAL; END ADT DD; Since an attribute is of a type such as an integer, real, string, etc, this information is essential. The problem is that an attribute cannot be all types at once, but only one Cf. il CJ -m.

U1 Ox 30 typ, varför man måste välja vissa olika typer och tillföra mera information. Detta sker genom typen Which0ne: TYPE WhiChOne IS ENUM IntDD, RealDD, TextDD, EnumDD, 0ctetDD, RangeDD, Arrayon , StructDD, RefDD, ExtDD END TYPE; Reguljära typer av attribut är naturligtvis heltal, decimal eller textsträng, och de skulle kunna specifiseras ungefär enligt: ADT TeXtDD IS ATTRIBUTES isString: Boolean:= True; END ADT TextDD; ADT RealDD IS ATTRIBUTES is32bit: Boolean:= True; END ADT RealDD Det finns dessutom vissa andra vanliga typer, som ej bör glömmas, såsom oktettsträng och uppräknade (enumerated): ADT OCtetDD IS ATTRIBUTES isøctet: Boolean:= True; END ADT 0CtetDD; ADT EnumDD IS ATTRIBUTES myEnumList: EnumElementArray; END ADT EnumDD; TYPE EnumElementArray IS END ADT END 4-79 456 31 ARRAY OF EnumElement TYPE EnumElement IS ATTRIBUTES myName: String; myvaluez Unsigned; ADT EnumElement; Det finns även andra typer, som ej är så vanliga, men ändå nödvändiga för att möjliggöra beskrivning av ett attribut helt, såsom strukturell typ och fälttyp (struct och array). Man kan även specificera egna typer. Range är en som skulle kunna vara av denna kategori: ADT END ADT END ADT END ADT END ADT ArrayDD IS ATTRIBUTES myElement: DD; mySize: Integer OPTIONAL; ADT ArrayDD; StructDD IS ATTRIBUTES myAttributeList: AttributeArray; ADT structnn; Rangeoo Is ATTRIBUTES myMin: Integer:= 0; myMax: Integer:=1; ADT RangeDD; ExternalDD IS ATTRIBUTES myClassName: ADT Externa1DD; String:= "NIL"; ReferenceDD IS ATTRIBUTES myClassId: Integer :=0; myClassName: String :="NIL"; . [IN x. 1] C) -PS 01 CA 32 myïnversez Integer OPTIONAL; END ADT ReferenceDD; Ett attribut kan även ha ett default-värde. För att kunna inkludera denna information specificeras en speciell "default value"-typ. Denna typ använder även typen whichøne för att ange vad för slags default-värde det rör sig om: ADT Default IS ATTRIBUTES whichOne: Whichüne myIntDD: IntDefault OPTIONAL; myRealDD: RealDefault OPTIONAL; myTextDD: TextDefault OPTIONAL; myEnumDD: EnumDefault OPTIONAL; my0ctetDD: OctetDefault OPTIONAL; myRangeDD: RangeDefault OPTIONAL; END ADT Default; ADT IntDefault IS ATTRIBUTES myUnSignedValue; Unsignedïnteger OPTIONAL; mySignedValue: Integer OPTIONAL; END ADT IntDefault; ADT Realbefault IS ATTRIBUTES my32bitValue: Real OPTIONAL END ADT Rea1Default; ADT TextDefault IS ATTRIBUTES myString: String OPTIONAL myChar: Character OPTIONAL; END ADT TextDefault; ADT EnumDefault IS ATTRIBUTES myvalue: EnumElement; END ADT EnumDefault; WG 456 33 ADT OctetDefault IS ATTRIBUTES myvaluez Octetstring; END ADT OctetDefault; ADT Rangebefault IS ATTRIBUTES myvaluez Integer; END ADT RangeDefault; Ett hanterat system kan specificeras med båda attribut, metoder, notifikation o.s.v. Genom användning av denna teknik för att specificera information kan allt passa i MIM-server- klassen. Nedan följer en lista av vissa andra typer av informa- tion som bör lagras: TYPE ActionArray IS ARRAY OF Action END TYPE; ADT Action IS ATTRIBUTES myName: String :="NIL"; myInternId: Integer :=0; myExternId: IntegerArray; myArguments: AttributeArray; myReturnType: DD; END ADT Action; TYPE NotificationArray IS ARRAY OF Notification END TYPE; ADT Notification IS ATTRIBUTES myName: String :="NIL"; myInternId: Integer :=0; myExternId: IntegerArray myArguments: AttributeArray; END ADT Notification; .p.U1 Ox 30 type, why you have to choose certain different types and add more information. This is done through the Which0ne type: TYPE WhiChOne IS ENUM IntDD, RealDD, TextDD, EnumDD, 0ctetDD, RangeDD, Arrayon, StructDD, RefDD, ExtDD END TYPE; Regular types of attributes are, of course, integers, decimals or text string, and they could be specified approximately according to: ADT TeXtDD IS ATTRIBUTES isString: Boolean: = True; END ADT TextDD; ADT RealDD IS ATTRIBUTES is32bit: Boolean: = True; END ADT RealDD There are also some other common types, which should not be forgotten, such as octet string and enumerated: ADT OCtetDD IS ATTRIBUTES isøctet: Boolean: = True; END ADT 0CtetDD; ADT EnumDD IS ATTRIBUTES myEnumList: EnumElementArray; END ADT EnumDD; TYPE EnumElementArray IS END ADT END 4-79 456 31 ARRAY OF EnumElement TYPE EnumElement IS ATTRIBUTES myName: String; myvaluez Unsigned; ADT EnumElement; There are also other types, which are not so common, but still necessary to enable the description of an attribute entirely, such as structural type and field type (struct and array). You can also specify own types. Range is one that could be of this category: ADT END ADT END ADT END ADT END ADT ArrayDD IS ATTRIBUTES myElement: DD; mySize: Integer OPTIONAL; ADT ArrayDD; StructDD IS ATTRIBUTES myAttributeList: AttributeArray; ADT structnn; Rangeoo Is ATTRIBUTES myMin: Integer: = 0; myMax: Integer: = 1; ADT RangeDD; ExternalDD IS ATTRIBUTES myClassName: ADT Externa1DD; String: = "NIL"; ReferenceDD IS ATTRIBUTES myClassId: Integer: = 0; myClassName: String: = "NIL"; . [IN x. 1] C) -PS 01 CA 32 myinverse Integer OPTIONAL; END ADT ReferenceDD; An attribute can also have a default value. To be able to include this information specified a special "default value "type. This type also uses the type whichøne to specify what kind of default value is it: ADT Default IS ATTRIBUTES whichOne: Whichüne myIntDD: IntDefault OPTIONAL; myRealDD: RealDefault OPTIONAL; myTextDD: TextDefault OPTIONAL; myEnumDD: EnumDefault OPTIONAL; my0ctetDD: OctetDefault OPTIONAL; myRangeDD: RangeDefault OPTIONAL; END ADT Default; ADT IntDefault IS ATTRIBUTES myUnSignedValue; UnsignedInteger OPTIONAL; mySignedValue: Integer OPTIONAL; END ADT IntDefault; ADT Realbefault IS ATTRIBUTES my32bitValue: Real OPTIONAL END ADT Rea1Default; ADT TextDefault IS ATTRIBUTES myString: String OPTIONAL myChar: OPTIONAL Character; END ADT TextDefault; ADT EnumDefault IS ATTRIBUTES myvalue: EnumElement; END ADT EnumDefault; WG 456 33 ADT OctetDefault IS ATTRIBUTES myvaluez Octetstring; END ADT OctetDefault; ADT Rangebefault IS ATTRIBUTES myvaluez Integer; END ADT RangeDefault; A managed system can be specified with both attributes, methods, notification, etc. Through the use of this technology to specify information, everything can fit in the MIM server the class. Below is a list of some other types of information tion that should be stored: TYPE ActionArray IS ARRAY OF ACTION END TYPE; ADT Action IS ATTRIBUTES myName: String: = "NIL"; myInternId: Integer: = 0; myExternId: IntegerArray; myArguments: AttributeArray; myReturnType: DD; END ADT Action; TYPE NotificationArray IS ARRAY OF NOTIFICATION END TYPE; ADT Notification IS ATTRIBUTES myName: String: = "NIL"; myInternId: Integer: = 0; myExternId: IntegerArray myArguments: AttributeArray; END ADT Notification; .p.

~J Û 1:56 34 TYPE NameBindingArray IS ARRAY OF Name Binding END TYPE; ADT Nameßinding IS ATTRIBUTES my0wnC1assName: String; myOwnClassID: Integer; myChildClassName String; myChildClassID: Integer; myChildRDNAttributeName: String; myChildRDNAttributeID: Integer; END ADT Nameßinding; Alla MIM-server-objekt bildar tillsammans det hanterade systemets totala modell. Med hjälp av denna nya typ av objekt blir det möjligt för driftstödsystemet att få information om det hanterade systemet bit för bit. Det blir även möjligt att ändra det hanterade systemet (d.v.s. modellen) under drift och låta driftstödsystemet uppdatera sin vy av det hanterade systemet utan omkompilering, genom läsning av information i MIM-server- objekten, som installerats i det hanterade systemet.~ J At 1:56 34 TYPE NameBindingArray IS ARRAY OF Name Binding END TYPE; ADT Nameßinding IS ATTRIBUTES my0wnC1assName: String; myOwnClassID: Integer; myChildClassName String; myChildClassID: Integer; myChildRDNAttributeName: String; myChildRDNAttributeID: Integer; END ADT Name Setting; All MIM server objects together form the managed one the overall model of the system. Using this new type of object it will be possible for the operational support system to obtain information about it handled the system bit by bit. It will also be possible to change the managed system (i.e. the model) during operation and sound the operating support system update its view of the managed system without recompiling, by reading information in the MIM server the objects, which are installed in the managed system.

Fig. 22 åskådliggör relationen mellan MIM-server-instanserna och klasserna av styrda objekt. För varje klass 120 resp. 122 av "normala" styrda objekt finns det en instans 124 resp. 126 av en klass 128 av "speciella" styrda objekt i det hanterade systemet -,130. Dessa "speciella" styrda objekt bildar representationen av driftstödsinformationsmodellen 132 av det hanterade systemet.Fig. 22 illustrates the relationship between the MIM server instances and the classes of controlled objects. For each class 120 resp. 122 av "normal" controlled objects, there is an instance 124 resp. 126 of a Class 128 of "special" controlled objects in the managed system -, 130. These "special" controlled objects form the representation of the operating support information model 132 of the managed system.

För uppdatering av det hanterade systemet behöver endast ett nytt MIM-server-objekt installeras för att reflektera den nya objekttypen i det hanterade systemet. Driftstödsystemet kan hämta den på samma sätt som skett med alla andra MIM-server- objekt, och det kommer nu att finnas en uppdaterad vy av det hanterade systemet utan omkompilering av koden. Detta gör drift- stödsystemet mycket stabilt och det hanterade systemet kan uppdateras ofta utan att man behöver bekymra sig om uppdatering av driftstödsystemet.To update the managed system, only one is needed new MIM server object is installed to reflect the new one the object type in the managed system. The operating support system can download it in the same way as with any other MIM server object, and there will now be an updated view of it handled the system without recompiling the code. This makes operational the support system is very stable and the managed system can updated frequently without having to worry about updating of the operating support system.

Som inledning till en närmare beskrivning nedan av ett utföringsexempel på MIM-server-kodgenerering, skall här först en kort sammanfattning ges av det som beskrivits tidigare med f-”i-70 456 35 hänvisning till fig. 2.As an introduction to a more detailed description below of one execution example of MIM server code generation, here one must first brief summary is given of what has been described previously with f- ”i-70 456 35 reference to Fig. 2.

Genereringen av MIM-server- och M0-koden är en kedja som _ börjar med specifikationen av M0, jfr fig. 23. Först specifice- rar konstruktören M0 med användning av ett speciellt specifika- tionssprâk, och kompilerar därpå koden med användning av en särskilt kompilator. Kompilatorn skapar källkoder i ett stan- dardprogrammeringsspråk såsom C eller C++. Huvudmålskoden är naturligtvis den exekverbara koden för det hanterade systemet, men detta är också den perfekta tidpunkten för generering av mellanformat för styrt objekts del av driftstödinformationsmo- dellen. För att kunna göra detta måste kompilatorn ha kännedom om strukturen hos MIM-server-klassen. Kompilatorn betraktar M0- specifikationen och räknar antalet attribut, metoder etc. och använder denna information för att konstruera en MIM-server-in- stans. All denna information införs i en "Klass-metod" i det ha- nterade systemets källkod och kan fritt exekveras efter instal- lation i det hanterade systemet.The generation of the MIM server and M0 code is a chain that _ begins with the specification of M0, cf. Fig. 23. First the specification constructor M0 using a special specification language, and then compiles the code using a especially compiler. The compiler creates source codes in a standard standard programming languages such as C or C ++. The main target code is of course the executable code of the managed system, but this is also the perfect time for generating intermediate format for the controlled object's part of the operational support information dellen. To be able to do this, the compiler must have knowledge about the structure of the MIM server class. The compiler considers M0- the specification and counts the number of attributes, methods, etc. and uses this information to construct a MIM server stop. All this information is entered in a "Class method" in the system source code and can be freely executed after installation in the managed system.

Användning av den beskrivna tekniken garanterar att modellen överensstämmer med det objekt den beskriver, eftersom genere- ringen av MIM-server-information och av objektkod härrör från samma MO-specifikation. Den gör det även lättare för M0-kon- struktören, som har till uppgift att generera modellinformation.Use of the described technology guarantees that the model corresponds to the object it describes, since the generating the ringing of MIM server information and of object code originates from same MO specification. It also makes it easier for the M0 con- the structure, which has the task of generating model information.

I själva verket gör den högautomatiserade kedjan av informa- tionsgenerering det inte bara lätt att konstruera styrda objekt, utan det kan även ske snabbt och tillförlitligt.In fact, the highly automated chain of information generation is not only easy to construct controlled objects, but it can also be done quickly and reliably.

Ett exempel på MIM-server-kodgenerering ges nu här: PERSISTENT BDT MO IS ATTRIBUTE8 time: Time; NrOfLinks: Integer; LinkName String; LinkId: String; HETHOD8 LockLink (IN aValue); END ADT MO; ADT Time IS ATTRIBUTES hour: IntRange(0,23), .. 22% v~_~'j (IQ) .fx C51 Ch 36 minute: IntRange(0,59); second: IntRange(0,59); END Time; Kompilatorn kommer att skapa källkod för objektet. I C++ skulle det kunna se ut ungefär enligt följande (Observera att koden ej är exakt utan endast har gjorts som exempel, varvid endast deklarationsfiler visas för klassen M0): class M0 public: H00: LockLink(aValue); void set_time(); void set_Nr0fLinks(); void set_LinkName(); void set_LinkId(); time get_time(); int get_NrOfLínks(); char* get_LinkName(); char* get_LinkId(); void init(); private: Time time; int Nr0fLinks; char* LinkName; char* Linkld; }; Eftersom Time var en komplex typ, kommer det även att vara en egen klass: class Time public: Time(); void set_hour(); void set_minute(); void set_second(); int get;hour(); int get_minute() int get_second(); void init(); private: int hour; 478 456 37 int minute; int second;}; Nu kan MIM-server-informationen genereras. Kompilatorn kommer att gå igenom M0-specifikationen och konstruera MIM-server- instansen bit för bit. Informationen kommer att samlas under en klassmetod, här benämnd mimlnit. void MO::MimInint() // Build the first attribute "Hour" IntRangeDD tmpIntRangeDD; tmpIntRangeDD.nyMin(0); tmpIntRangeDD.myMax(23); // Set the choice switch to IntRange WhichOne tmpWhichOne; tmpWhich0ne(IntRangeDD); // Set the DataDomain values DD tmpDD; tmpDD.whichOne(tmpWhichOne); tmpDD.myIntRangeDD(tmpIntRangeDD); // Set the attribute values Attribute tmpAttributel; tmpAttributel.myName("Hour"); tmpAttribute1.myDD(tmpDD); // Build the second attribute "Minute" IntRangeDD tmpIntRangeDD; tmpIntRangeDD.myMin(0); tmpIntRangeDD.myMax(59); WhichOneType tmpWhichOne; tmpWhichOne (IntRangeDD); DD tmpDD; tmpDD.whíchOne (tmpWhichOne); . Fm wa c.) $ß 0"! CSK 38 tmpDD.myIntRangeDD(tmpIntRangeDD); Attribute tmpAttribute2; tmpAttribute2.myName("Minute"); tmpAttríbute2.myDD(tmpRangeDD); // Build the third attribute "Second" IntRangeDD tmpIntRangeDD; tmpIntRangeDD.myMin(0); tmpIntRangeDD.myMax(59); Which0neType tmpWhichOne; tmpWhíchOne(IntRangeDD); DD tmpDD; tmpDD.which0ne(tmpwhichone); tmpDD.myIntRangeDD(tmpIntRangeDD); AttributeType tmpAttribute3; tmpAttribute3.myName("Second"); tmpAttribute3.myDD(tmpIntRangeDD); Hittills har endast de attribut skapats, av vilka Time består, varför nu även själva time-attributet måste skapas, øch tilldela de andra attributen till detta: AttributeArray tmpAttList; tmpAttList.add(tmpAttribute1); tmpAttList.add(tmpAttribute2); tmpAttList.add(tmpAttribute3); StructDD tmpStructDD; tmpStructDD.myAttList(tmpAttList); Which0neType tmpWhichOne; tmpwhich0ne(StructDD); DD tmpDD; tmpDD.whichOne(tmpWhichOne); tmpDD.myStructDD(tmpStructDD); Attribute tmpAttribute4; 4-70 4, .Jwl :Ü'\ 39 tmpAttribute4.myName(myTime); tmpAttribute4.myExternId("0ID“); tmpAttribute4.myInternId(l); tmpAttribute4.optional(FALSE); myDD(tmpDD); // Now myTime is done, the next tribute to do is NrOfLinks.An example of MIM server code generation is now given here: PERSISTENT BDT MO IS ATTRIBUTE8 time: Time; NrOfLinks: Integer; LinkName String; LinkId: String; HETHOD8 LockLink (IN aValue); END ADT MO; ADT Time IS ATTRIBUTES hour: IntRange (0.23), .. 22% v ~ _ ~ 'j (IQ) .fx C51 Ch 36 minute: IntRange (0.59); second: IntRange (0.59); END Time; The compiler will create source code for the object. In C ++ it could look something like this (Note that the code is not exact but has only been made as an example, whereby only declaration files are displayed for class M0): class M0 public: H00: LockLink (aValue); void set_time (); void set_Nr0fLinks (); void set_LinkName (); void set_LinkId (); time get_time (); int get_NrOfLínks (); char * get_LinkName (); char * get_LinkId (); void init (); private: Time time; int Nr0fLinks; char * LinkName; char * Linkld; }; Since Time was a complex type, it will also be one own class: class Time public: Time (); void set_hour (); void set_minute (); void set_second (); int get; hour (); int get_minute () int get_second (); void init (); private: int hour; 478 456 37 int minute; int second;}; The MIM server information can now be generated. The compiler is coming to go through the M0 specification and construct the MIM server instance piece by piece. The information will be gathered under one class method, here referred to as mimlnit. void MO :: MimInint () // Build the first attribute "Hour" IntRangeDD tmpIntRangeDD; tmpIntRangeDD.nyMin (0); tmpIntRangeDD.myMax (23); // Set the choice switch to IntRange WhichOne tmpWhichOne; tmpWhich0ne (IntRangeDD); // Set the DataDomain values DD tmpDD; tmpDD.whichOne (tmpWhichOne); tmpDD.myIntRangeDD (tmpIntRangeDD); // Set the attribute values Attribute tmpAttributel; tmpAttributel.myName ("Hour"); tmpAttribute1.myDD (tmpDD); // Build the second attribute "Minute" IntRangeDD tmpIntRangeDD; tmpIntRangeDD.myMin (0); tmpIntRangeDD.myMax (59); WhichOneType tmpWhichOne; tmpWhichOne (IntRangeDD); DD tmpDD; tmpDD.whíchOne (tmpWhichOne); . Fm wa c.) $ ß 0 "! CSK 38 tmpDD.myIntRangeDD (tmpIntRangeDD); Attribute tmpAttribute2; tmpAttribute2.myName ("Minute"); tmpAttríbute2.myDD (tmpRangeDD); // Build the third attribute "Second" IntRangeDD tmpIntRangeDD; tmpIntRangeDD.myMin (0); tmpIntRangeDD.myMax (59); Which0neType tmpWhichOne; tmpWhíchOne (IntRangeDD); DD tmpDD; tmpDD.which0ne (tmpwhichone); tmpDD.myIntRangeDD (tmpIntRangeDD); AttributeType tmpAttribute3; tmpAttribute3.myName ("Second"); tmpAttribute3.myDD (tmpIntRangeDD); So far, only those attributes have been created, of which Time consists, why now also the time attribute itself must be created, øch assign the other attributes to this: AttributeArray tmpAttList; tmpAttList.add (tmpAttribute1); tmpAttList.add (tmpAttribute2); tmpAttList.add (tmpAttribute3); StructDD tmpStructDD; tmpStructDD.myAttList (tmpAttList); Which0neType tmpWhichOne; tmpwhich0ne (StructDD); DD tmpDD; tmpDD.whichOne (tmpWhichOne); tmpDD.myStructDD (tmpStructDD); Attribute tmpAttribute4; 4-70 4, .Jwl : Ü '\ 39 tmpAttribute4.myName (myTime); tmpAttribute4.myExternId ("0ID"); tmpAttribute4.myInternId (l); tmpAttribute4.optional (FALSE); myDD (tmpDD); // Now myTime is done, the next tribute to do is NrOfLinks.

// Next attribute to build is NrOfLinks Intnn tmpïntnn; WhichOneType tmpWhich0ne; tmpwhichOne(IntDD); DD tmpDD; tmpDD.whíchOne(tmpWhich0ne); tmpDD.myIntDD(tmpIntDD); Attribute tmpAttribute5; tmpAttribute5;myName/NrOfLinks); tmpAttribute5;myExternId("0ID“); tmpAttribute5;myInternId(2); tmpAttribute5;optional(FALSE); tmpAttribute5;myDD(tmpDD); // The compiler keeps building attributes this way // until all attributes and so forth is created // After that it creates the MIM instance and // assigns the different attributes to it.// Next attribute to build is NrOfLinks Intnn tmpïntnn; WhichOneType tmpWhich0ne; tmpwhichOne (IntDD); DD tmpDD; tmpDD.whíchOne (tmpWhich0ne); tmpDD.myIntDD (tmpIntDD); Attribute tmpAttribute5; tmpAttribute5; myName / NrOfLinks); tmpAttribute5; myExternId ("0ID"); tmpAttribute5; myInternId (2); tmpAttribute5; optional (FALSE); tmpAttribute5; myDD (tmpDD); // The compiler keeps building attributes this way // until all attributes and so forth is created // After that it creates the MIM instance and // assigns the different attributes to it.

// The MIM instance is assigned the same name as the // classid of the class the information represents AttributeArray tmpAttList; tmpAttList.add(tmpAttribute4); tmpAttList.add(tmpAttribute5); tmpAttList.add(tmpAttribute6); tmpAttList.add(tmpAttribute7); Mim 24337; 2433.set_myClassName(myM0); -TX *w .u (I) .Fin (Å 'I Ö\ 40 2433.set_myClassID(24337); 2433.set_myVersion(1,0); 2433.set_myAttList(tmpAttList); // 24337.set_myNotificationList(tmpNotificationList); 24337.set_myNameBindingList(tmpNameBindingList); 24337.set_myActionList(tmpActionList); // } Klassen är nu färdig att kompileras av en vanlig C++ -kompi- lator, varpå den kan installeras i det hanterade systemet.// The MIM instance is assigned the same name as the // classid of the class the information represents AttributeArray tmpAttList; tmpAttList.add (tmpAttribute4); tmpAttList.add (tmpAttribute5); tmpAttList.add (tmpAttribute6); tmpAttList.add (tmpAttribute7); Mim 24337; 2433.set_myClassName (myM0); -TX * w .u (IN) .Nice (Å 'I ISLAND\ 40 2433.set_myClassID (24337); 2433.set_myVersion (1.0); 2433.set_myAttList (tmpAttList); // 24337.set_myNotificationList (tmpNotificationList); 24337.set_myNameBindingList (tmpNameBindingList); 24337.set_myActionList (tmpActionList); // } The class is now ready to be compiled by a standard C ++ compiler. lator, after which it can be installed in the managed system.

Metoden Mimlnit är nu färdig för exekvering, och en MIM-server- instans kommer att skapas med all införd information. Såsom beskrivits tidigare provas först mjukvaran och installeras därpå i det hanterade systemet.The Mimlnit method is now ready for execution, and a MIM server instance will be created with all entered information. As described previously, the software is first tested and then installed in the managed system.

För att kunna exekvera en metod som instansierar MIM-sever- klassen, krävs det naturligtvis att MIM-server-klassen redan har installerats i det hanterade systemet. MIM-server-klassen bör sålunda vara den första klassen som installeras i det hanterade systemet.In order to execute a method that instantiates MIM class, it is of course required that the MIM server class already has installed in the managed system. The MIM server class should thus being the first class to be installed in the managed the system.

Metoden Mimïnit är en klassmetod och är endast avsedd att exekveras en gång, och är således ej någon allmän metod som driftstödsystemet kan exekvera.The Mimïnit method is a class method and is only intended to executed once, and is thus not a general method that the operating support system can execute.

När det bestämts att ett hanterat system skall uppdateras med nya klasser måste mjukvaran provas noggrannt för användning. När allt detta skett och klasserna skall friges exekverar det hante- rade systemets mjukvara för uppdatering, Mimlnit-metoden i varje klass. Eftersom varje klass har sin egen Mimlnit-metod, kommer en instans av varje klass att installeras i databasen. Efter varje instansiering av MIM-klassen utsänds ett notifikation, som beskriver vilken klass det är som installerats. Driftstödsyste- met, som är abonnent på dessa notifikationer, erhåller natur- ligtvis notifikation och avgör vad som skall göras, förnyelse av gammal MIM-server-information eller åsidosättande av notifika- tionen.When it has been decided that a managed system should be updated with new classes, the software must be carefully tested before use. When all this has taken place and the classes are to be released, the system update software, the Mimlnit method in each class. Because each class has its own Mimlnit method, comes an instance of each class to be installed in the database. After each instantiation of the MIM class is sent a notification, which describes which class has been installed. Operational support system who subscribes to these notifications, naturally receives notification and decide what to do, renewal of old MIM server information or breach of notifications tion.

Att ha en representation av modellen av ett hanterat system i själva det hanterade systemet i stället för kodat i driftstöd- systemet har fördelen att den alltid överensstämmer med det WB 456 41 hanterat system den beskriver. Likaså kan ett driftstödsystem anslutas till ett godtyckligt hanterat system, läsa dess modell- representation och vara i stånd att hantera det. Det är även möjligt att låta det hanterade systemet ha en MIM-server-instans beskrivande själva MIM-server-klassen, eftersom det är en klass lik varje annan klass, som installeras i det hanterade systemet.To have a representation of the model of a managed system in the managed system itself instead of coded in the operating the system has the advantage that it always complies with it WB 456 41 managed system it describes. Likewise, an operational support system can connected to an arbitrarily managed system, read its model representation and be able to handle it. It is too possible to let the managed system have a MIM server instance describing the MIM server class itself, since it is a class like any other class installed in the managed system.

Detta skulle kunna leda till en hanterare som först skulle läsa MIM-server-instansen som beskriver MIM-server-klassen, dess version etc., och med denna information beslutar om hur MIM- server-instanserna i systemet skall tolkas.This could lead to a handler who would read first The MIM server instance that describes the MIM server class, its version, etc., and with this information decides how the MIM the server instances of the system must be interpreted.

Här skall nu en redogörelse ges för hur ett driftstödsystem tar upp och tolkar modellinformation lagrad i ett hanterat system.Here is now an account of how an operating support system records and interprets model information stored in a managed system.

För att kunna sända data mellan driftstödsystem och hanterat system och återställa informationen till dess ursprungsform krävs det att mottagningssystemet antingen känner exakt vad som är sänt och i vilken ordning, eller att informationen kan iden- tifiera sig själv, vanligen genom etiketter eller med andra ord identifieringselement. Vilken metod som än används behövs det viss gemensam information eller regler för att göra detta, ofta benämnt protokoll.To be able to send data between operating support systems and managed system and restore the information to its original form it is required that the reception system either knows exactly what is sent and in what order, or that the information may be identify themselves, usually through labels or in other words identification element. Whatever method is used, it is needed certain common information or rules to do so, often called protocol.

Eftersom olika datatyper kodas med olika bitantal, eller t.o.m. samma bitantal, är det viktigt att veta exakt hur många bitar som ingår i varje datatyp när man tolkar den mottagna bitsträngen. Detta är ett vanligt problem i detta sammanhang och en mängd olika protokoll finns. För att välja mellan de olika sätten att sända och återskapa data måste man ta hänsyn till att informationen kan vara ganska komplex, och när man väl har informationen i det mottagande systemet måste den struktureras på ett användbart sätt.Because different data types are encoded with different bit numbers, or Empty. the same number of bits, it is important to know exactly how many bits that are included in each data type when interpreting the received one the bit string. This is a common problem in this context and a variety of protocols are available. To choose between the different Ways to send and recreate data must be taken into account The information can be quite complex, and once you have the information in the receiving system, it must be structured in a useful way.

Modellinformationen bör därför representeras i en struktur, som är känd av båda de kommunicerande sidorna. För kodning och avkodning av enkla datatyper till bitsträngar används i den här beskrivna utföringsformen det kodnings- och avkodningssystem, som används i det hanterade systemet för dess inre kommunika- tion. Detta kodnings- och avkodningssystem måste vara känt för båda sidor av länken för att undvika korrumpering av data.The model information should therefore be represented in a structure, known by both the communicating sides. For coding and decoding of simple data types into bit strings is used in this described embodiment the coding and decoding system, used in the managed system for its internal communication tion. This encoding and decoding system must be known for both sides of the link to avoid data corruption.

Grundläggande för överföring av enkla datatyper till kommuni- cerbara bitsträngar är att ha en strategi avseende kodningen och ...En °-Cl C11) .J_T~..~.Basics for transferring simple data types to communications cerable bit strings is to have a coding strategy and ...One ° -Cl C11) .J_T ~ .. ~.

O' I _; x 42 avkodningen av dessa bitsträngar. Det här använda förfarandet är att låta en heltalstyp använda 32 bitar för att representera dess värde. En sträng är kodad med användning av 32 bits heltal representerande antalet tecken i strängen, och varje tecken representeras med 8 bitar.O 'I _; x 42 the decoding of these bit strings. The procedure used here is to let an integer type use 32 bits to represent its value. A string is encoded using 32-bit integers representing the number of characters in the string, and each character represented by 8 bits.

För kodning av enkla datatyper till kommunicerbara bitsträng- ar har varje datatyp en skiftmetod, som enkelt åskådliggör vad som händer: Koda Avkoda int>>bitstring bitstring>>int float>>bitstring bitstring>>float char*>>bitstring bitstríng>>char* char>>bitstring bitstríng>>char boolean>>bitstring bitstring>>boolean v o Genom användning av kodnings- och avkodningsprinciperna för enkla datatyper kan man skapa kodnings- och avkodningsmetoder för mera komplexa datastrukturer. Detta sker enkelt genom imple- mentering av metoden som en serie av enkla kodnings- eller avkodningsmetoder: complex Buffer operator >>(Buffer buf, complex X) { { int a; buf>>X.a; char*b; buf>>X.b; } } Buffer operator<<(Buffer buf,complex X) { buf< buf< } Genom användning av denna teknik för att konstruera kodnings- och avkodningsmetoderna för komplexa datastrukturer kan man konstruera så gott som varje slags kodnings- eller avkodnings- metod.For encoding simple data types into communicable bit strings Each data type has a shift method, which easily illustrates what that happens: Koda Avkoda int >> bitstring bitstring >> int float >> bitstring bitstring >> float char * >> bitstring bitstring >> char * char >> bitstring bitstring >> char boolean >> bitstring bitstring >> boolean v o By using the coding and decoding principles for simple data types, you can create encoding and decoding methods for more complex data structures. This is easily done by implementing implementation of the method as a series of simple coding or decoding methods: complex Buffer operator >> (Buffer buf, complex X) {{ int a; buf >> X.a; char * b; buf >> X.b; }} Buffer operator << (Buffer buf, complex X) { buf < buf < } By using this technique to construct the coding and the decoding methods for complex data structures can be construct virtually any type of coding or decoding method.

När ett driftstödsystem initierar en läsoperation mot en instans i det hanterade systemet måste det ange vilket attribut ê-7G 456 43 det önskar läsa. Datat i attributet kodas med användning av tidigare beskrivna metoder, sänds till driftstödsystemet, samt avkodas därpå. Om det mottagande systemet har samma kodnings- och avkodningsmetoder som sändningssystemet, och mottagaren känner till vilken metod, som används för avkodning av denna information, kommer det inte att vara något problem att läsa komplex information.When an operating support system initiates a read operation against one instance in the managed system, it must specify which attribute ê-7G 456 43 it wants to read. The data in the attribute is encoded using previously described methods, sent to the operational support system, and decoded thereafter. If the receiving system has the same coding and decoding methods such as the transmission system, and the receiver know which method is used to decode it information, it will not be a problem to read complex information.

För att möjliggöra tolkning av MIM-information införlivas MIM-server-klassens kodnings- och avkodningsrutiner i driftstöd- hanteraren. Därigenom kan informationen, som mottages från det hanterade systemet tolkas genom att en instans av MIM-server- klassen görs, och därpå bitar skiftas ut från databufferten in i MIM-server-instansen.To enable interpretation of MIM information is incorporated MIM server class encoding and decoding routines in operating support the handler. Thereby, the information received from it can managed system is interpreted by an instance of the MIM server the class is made, and then bits are replaced from the data buffer into MIM server instance.

Driftstödsystemet innehåller MIM-server-klassen i sin tolk- ningsdel modelltolk i fig. 15, och när det läser attributvärdena från en MIM-server-instans i det hanterade systemet, och motta- ger en buffert med kodade data, avkodas data lätt genom utskift- ning av bitarna ur buffertarna in i en tom lokal instans av MIM- server-klassen. Eftersom MIM-server-klassen har metoder för skiftning av data till och från buffertar blir detta en lätt uppgift. Huvudproblemet uppträder vid tolkning av andra klasser än MIM-server. I detta fall måste man använda MIM-server-in- formationen för att avkoda information.The operational support system contains the MIM server class in its model interpreter in Fig. 15, and when reading the attribute values from a MIM server instance in the managed system, and receive provides a buffer with encoded data, the data is easily decoded by transfer the bits from the buffers into an empty local instance of the MIM server class. Because the MIM server class has methods for shifting data to and from buffers makes this an easy one task. The main problem occurs when interpreting other classes than MIM server. In this case, you must use the MIM server formation to decode information.

Ytterligare förklaring kan hämtas från det utföringsexempel, som nu beskrivs nedan med hänvisning till fig. 24-28.Further explanation can be taken from the embodiment, as now described below with reference to Figs. 24-28.

För att tolka attributvärden, som lästs från ett vanligt M0, behöver driftstödsystemet ha MIM-server-information, som be- skriver MO-klassen. Det börjar med att skapa en tom instans av MIM-server och ett handtag (UsrM0) för de från det vanliga MO lästa attributvärdena. 1. MIM local_MIM_Link; //skapar en MIM-serverinstans. 2. UsrM0 local_UsrMO_Link; //skapar en UsrM0 instans. 3. get(MIM,Link,myAttList); //läser modellinformation.To interpret attribute values, read from a standard M0, the operating support system needs to have MIM server information, which writes the MO class. It starts with creating an empty instance of MIM server and a handle (UsrM0) for those from the regular MO read the attribute values. 1. MIM local_MIM_Link; // creates a MIM server instance. 2. UsrM0 local_UsrMO_Link; // creates a UsrM0 instance. 3. get (MIM, Link, myAttList); // reads model information.

Ovanstående tre moment åskådliggörs i fig. 24. 4. Buffer>>local_MIM;Link.myAttList;// kopian fylls med in- formation.The above three steps are illustrated in Fig. 24. 4. Buffer >> local_MIM; Link.myAttList; // copy is filled in with formation.

Driftstödsystemet kan nu titta i den lokalt representerade MIM-servern och undersöka klassen Link. Nästa steg är att här- leda det instansdata från MO-objektet, som det var intresserat 4178 f-É-Sá 44 av. Denna procedur är något mer komplicerad, men kan genomföras i följande moment.The operating support system can now look in the locally represented MIM server and examine the Link class. The next step is to lead the instance data from the MO object, which it was interested 4178 f-É-Sá 44 of. This procedure is slightly more complicated, but can be performed in the following steps.

I fig. 25 åskâdliggörs hur driftstödsystemet härleder in- stansdata från länk A. 5. get(Link, A,all); läs alla attributvärden.Fig. 25 illustrates how the operating support system derives the punch data from link A. 5. get (Link, A, all); read all attribute values.

Nu ligger instansdata från A i en lista av buffertar väntande på att avkodas. Driftstödsystemet kommer nu att använda skift- operationer för att erhålla rätt mängd bitar och avkoda dessa till rätt datatyp.Now instance data from A is in a list of buffers pending to be decoded. The operational support system will now use shift operations to obtain the correct amount of bits and decode them to the correct data type.

Genom att titta i den lokala MIM-servern för att avgöra vilken datatyp det första attributet är, kan det första attri- butet erhållas och avkodas från bufferten.By looking in the local MIM server to determine which data type the first attribute is, the first attribute butet is obtained and decoded from the buffer.

Fig. 26 åskådliggör hur den lokala MIM-servern, representer- ande MO-klassen, används för att bygga den första lokala repre- sentationen av MO-instansen. 6. När driftstödsystemet kommer till datatypen Date, upp- täcker det att den är strukturerad, och behöver gå ned i struk- turen för ytterligare undersökning. Detta åskådliggörs av fig. 27. 7. Tolken tittar i strukturen "date" och går igenom dess attributlista för att söka efter attributdatatyperna. Med an- vändning av denna information kan nästa buffert tolkas. Detta åskådliggörs även i fig. 28. 8. Tolkningen är genomförd och driftstödsystemet är i stånd att presentera attributvärdena för en yttre användare. Fig. 29 visar hur datat är tolkat och nästa attributtyp läses från den lokala MIM-server representationen.Fig. 26 illustrates how the local MIM server, represented the MO class, is used to build the first local repre- the presentation of the MO instance. 6. When the operating support system reaches the data type Date, it covers that it is structured, and needs to go down in the the tour for further investigation. This is illustrated by FIG. 27. 7. The interpreter looks in the structure "date" and goes through it attribute list to search for attribute data types. With an- inversion of this information, the next buffer can be interpreted. This is also illustrated in Fig. 28. 8. The interpretation has been completed and the operational support system is in place to present the attribute values to an external user. Fig. 29 shows how the data is interpreted and the next attribute type is read from it local MIM server representation.

Här skall nu beskrivas hur den tidigare ovan diskuterade driftstödinformationsmodellen kan göras bestämbar. Med detta avses här att det bör vara möjligt för ett datorprogram att läsa dess specifikation och tolka: - vilka tillstånd det hanterade systemet kan inta (tillstånd som är av intresse från driftstödsystemets synpunkt) - vilka operationer, som kan riktas mot det hanterade systemet. - vilka operationer, som kan riktas mot ett hanterat system i ett visst tillstånd och slutligen - vilket tillstånd det hanterade systemet hamnar i när en viss operation riktas mot det. låfíü 456 45 För att kunna kallas bestämbar måste driftstödinformations- modellen kunna uttryckas i maskintolkningsbart språk. Inom kon- ventionell teknologi används oftast naturligt språk för att uttrycka vilka operationer som kan riktas mot ett hanterat system och vilket tillstånd det hanterade systemet hamnar i när en viss operation riktas mot det.Here it will now be described how the one previously discussed above the operational support information model can be made determinable. With this means here that it should be possible for a computer program to read its specification and interpret: which permissions the managed system can take (permissions of interest from the point of view of the operating aid scheme) - which operations, which can be directed at the handled the system. which operations can be directed at a managed system in a certain state and finally - what state the managed system ends up in when one some operation is directed at it. låfíü 456 45 In order to be called determinable, the operating aid information the model can be expressed in machine-interpretable language. Within the con- conventional technology is most often used natural language to express which operations can be directed at a managed system and what state the managed system ends up in when a certain operation is directed at it.

Genom att göra specifikationen bestämbar uppnår man ett antal fördelar: - En generell driftstödhanterare kan göras mer kraftfull, eftersom den kan förutsäga det nya tillståndet hos det hanterade systemet efter en viss operation, och den kan även föreslå sådana operationer som är tillåtna i ett visst tillstånd, och/eller leder till önskat tillstånd.By making the specification determinable, a number is achieved benefits: - A general operational support manager can be made more powerful, because it can predict the new state of the managed system after a certain operation, and it can also suggest such operations as are permitted in a particular condition, and / or leads to the desired condition.

- Implementeringen och verifieringen av de hanterade systemen liksom (icke generella) driftstödhanteringstillämpningar förenk- las eftersom det väntade uppförandet specificeras väl. Det blir också möjligt att generera en stor del av implementeringskoden från specifikationen.- The implementation and verification of the managed systems as well as (non-general) operational support management applications read because the expected behavior is well specified. It becomes also possible to generate a large part of the implementation code from the specification.

- Robustheten under drift förbättras eftersom endast opera- tioner, som leder till tillåtna tillståndsövergångar i de hante- rade systemen accepteras.- The robustness during operation is improved because only leading to permissible transfers of licenses in the systems are accepted.

- Tidig emulering och värdering av driftstödinformationsmo- dellen underlättas, vilket gör specifikationsuppgiften enklare.- Early emulation and evaluation of operational support information the part is facilitated, which makes the specification task easier.

- Driftstödmodellen kan modelleras till att bli både robust och lätt att använda, genom att medge en ganska fri sekvens av operationer men fortfarande garantera en komplett konfigurering av det hanterade systemet innan konfigureringen inställs i verksamt tillstånd.- The operational support model can be modeled to be both robust and easy to use, by allowing a fairly free sequence of operations but still guarantee a complete configuration of the managed system before setting the configuration in effective condition.

Här skall nu först möjliga tillstånd definieras.Here, first possible conditions must now be defined.

Tillståndet hos ett hanterat system i ett visst ögonblick anges av vilka instanser av styrda objekt och vilka attributvär- den dessa instanser har i det hanterade systemet i detta ögon- blick.The state of a managed system at a given moment indicates which instances of controlled objects and which attribute values these bodies have in the managed system in this glance.

För att definiera det tillstånd ett visst hanterat system kan inta måste definition ges av: - vilka instanser av hanterade objekt, som kan existera och - vilka attribut de har och - vilka värden dessa attribut kan ha.To define the state a certain managed system can inta must be defined by: which instances of managed objects, which can exist and what attributes they have and - what values these attributes can have.

Av den i fig. 30 givna specifikationen, rad 1, framgår att UI 46 det skulle kunna finnas hanterade objekt av klassen Subscriber.From the specification given in Fig. 30, line 1, it appears that UI 46 there could be managed objects of the class Subscriber.

Hanterade objekt av denna klass har attributen, raderna 3-8: - Number, som anger abonnentnummer, Admstate, som anger administrativt tillstånd, 0pState, som anger operativt tillstånd, Usagestate, som anger användningstillstånd, Line, som ger referens till linjedrivenhet för abonnen- tens fysiska terminal.Managed objects of this class have the attributes, rows 3-8: Number, which indicates the subscriber number, Admstate, which indicates administrative status, 0pState, which indicates the operating state, Usagestate, which states the use permit, Line, which provides a reference to the line driver for the subscriber its physical terminal.

Den möjliga tillståndsrymden för ett hanterat system utvidgas genom denna specifikation. Den nya tillståndsrymden består av nya potentiella abonnenter med alla möjliga kombinationer av attributvärden.The possible state space for a managed system is expanded through this specification. The new state space consists of new potential subscribers with all possible combinations of attribute values.

De potentiella attributvärdena bestäms av attributens typ enligt fig. 31, raderna 24, 28, 32, 37, 41.The potential attribute values are determined by the type of attributes according to Fig. 31, rows 24, 28, 32, 37, 41.

Här följer nu en beskrivning av hur möjliga operationer definieras.Here now follows a description of how possible operations defined.

Mot det hanterade systemet riktade operationer skapar, raderar, manipulerar och inspekterar instanser av styrda objekt och kan sålunda ändra det hanterade systemets tillstånd.Towards the managed system, targeted operations create, deletes, manipulates and inspects instances of controlled objects and can thus change the state of the managed system.

Skapaoperationen skapar en ny instans av en angiven klass av styrda objekt.The create operation creates a new instance of a specified class of controlled objects.

Raderingsoperationen tar bort styrda objekt.The delete operation removes controlled objects.

Skrivoperationen ändrar värdet på ett attribut hos en instans av en klass av styrda objekt.The write operation changes the value of an attribute of an instance of a class of controlled objects.

Metodoperationen anropar en metod hos en instans för en klass av styrda objekt.The method operation calls a method in an instance of a class of controlled objects.

Läsoperationen returnerar värdet på ett attribut hos en instans.The read operation returns the value of an attribute of a instance.

Läs-, skriv-, skapa- och radera-operationerna är generella och har samma syntax och semantiska regler för alla klasser av styrda objekt. Skapa- och radera-operationerna specificeras som möjliga, eller icke möjliga för en viss klass av styrda objekt.The read, write, create and delete operations are general and has the same syntax and semantic rules for all classes of controlled objects. The create and delete operations are specified as possible, or not possible for a particular class of controlled objects.

Läs-operatíonerna är alltid möjliga för varje attribut hos en klass av styrda objekt och specificeras sålunda implicit vid definition av attributet och dess typ.The read operations are always possible for each attribute of one class of controlled objects and is thus implicitly specified at definition of the attribute and its type.

Skrivoperationen är valfri och specificeras såsom definieran- de ett attribut som uppdaterbart.The write operation is optional and is specified as defined they an attribute as updatable.

Metodoperationen är en utväg till en operation specifik för en klass av styrda objekt. Dessa operationer utförs som metoder. 47 Varje metod definieras som en metod mot instanser hos klassen av styrda objekt. Varje metod mottager en lista av parametrar som indata och returnerar ett resultat.The method operation is a way out of an operation specific to a class of controlled objects. These operations are performed as methods. 47 Each method is defined as a method against instances of the class of controlled objects. Each method receives a list of parameters such as input data and returns a result.

Fig. 32 definierar operationer. På raderna 61-64 definieras följande operationer: - Läs-operationer av attribut Line, Number, Admstate, 0pState, Usagestate, raderna 62-63, - Skrivoperation av attributet Line, rad 61, - Metoden LockRequest, rad 64.Fig. 32 defines operations. On lines 61-64 are defined the following operations: - Read operations of attributes Line, Number, Admstate, 0pState, Usagestate, lines 62-63, - Write operation of the attribute Line, line 61, - LockRequest method, line 64.

Detta hanterade objekt definieras såsom ej uppvisande någon radera- eller skapa-operation, rad 65.This managed object is defined as not having any delete or create operation, line 65.

Här följer nu en beskrivning av hur tillåtna kombinationer av operation/tillstånd kan specificeras.Here now follows a description of how permitted combinations of operation / condition can be specified.

Beroende på vilka instanser av styrda objekt, som finns i ett hanterat system samt deras attributvärden, finns det en unik uppsättning av tillåtna operationer i ett visst tillstånd. Ett exempel är att en instans ej kan raderas om den är i bruk (vil- ket anges med ett attribut). Ett annat exempel är att det ej är tillåtet att skapa en tionde instans av någon klass av styrda objekt, eftersom det finns en implementeringsberoende begräns- ning, som anger att det endast får finnas nio instanser.Depending on which instances of controlled objects, which are in one managed system as well as their attribute values, there is a unique set of permitted operations in a certain state. One example is that an instance cannot be deleted if it is in use (which indicated by an attribute). Another example is that it is not allowed to create a tenth instance of any class of governed objects, as there is an implementation-dependent constraint which states that there may only be nine instances.

I princip finns det två sätt att specificera dessa kombina- tioner av operation/tillstånd, nämligen genom förvillkor och/el- ler slutvillkor.In principle, there are two ways to specify these combinations. operations / permits, namely through preconditions and / or smiles final terms.

Ett förvillkor anger vilka villkor som måste vara uppfyllda för att en operation skall godkännas. I föreliggande fall anges för varje operation vilket tillstånd det hanterade systemet måste befinna sig i för att acceptera instruktionen. Förvillko- ren utgör en logisk del av klassen av styrda objekt.A prerequisite indicates which conditions must be met for an operation to be approved. In the present case stated for each operation the state of the managed system must be in to accept the instruction. Conditions pure is a logical part of the class of controlled objects.

I vårt exempel med objektklassen Subscriber, önskar vi förhindra att attributet Line töms (sätts till NULL) innan abonnenten deblockeras (anges genom att attributet Adm- State=unlocked. Line-attributet är som nämnts referensen till linjedrivenheten för abonnentens fysiska terminal. Vi önskar garantera att denna referens föreligger när Subscriber används.In our example with the object class Subscriber, we wish prevent the Line attribute from being emptied (set to NULL) before the subscriber is unblocked (indicated by the Admin State = unlocked. The line attribute is, as mentioned, the reference to the line driver for the subscriber's physical terminal. We wish ensure that this reference exists when using Subscriber.

Raderna 79 och 80 i fig. 33 visar hur detta kan uttryckas.Lines 79 and 80 in Fig. 33 show how this can be expressed.

Ett slutvillkor anger vilka villkor som måste vara uppfyllda efter en uppdateringstransaktion. I föreliggande fall kan man för varje klass av styrda objekt ange vilket tillstånd instan- :'15 _¿ .Û L:- 6 48 serna av klassen måste befinna sig i för att vara i ett konsi- stent tillstånd. Slutvillkoren är logiskt en del av en klass av styrda objekt eller en grupp av sådana klasser. Det senare gäller för beroenden mellan objekt.A final condition indicates which conditions must be met after an update transaction. In the present case, one can for each class of controlled objects, indicate the state of the : '15 _¿ .Û L: - 6 48 the class must be in order to be in a consistent stent condition. The final terms are logically part of a class of controlled objects or a group of such classes. The latter applies to dependencies between objects.

I föreliggande exempel med objektklassen Subscriber önskar vi förhindra att attributet Admstate är oblockerat om attributet Line är tömt. Vi önskar säkerställa att den sistnämnda referen- sen föreligger när abonnenten används. I fig. 34 uttrycks detta på raderna 106 och 107.In the present example with the object class Subscriber we wish prevent the Admstate attribute from being unblocked if the attribute Line is empty. We wish to ensure that the latter reference then exists when the subscriber is used. In Fig. 34 this is expressed on lines 106 and 107.

Ett slutvillkor kan uppfyllas på endera av två sätt. Drift- stödsystemet uppdaterar det hanterade systemet på sådant sätt att slutvillkoren upprätthålls. I detta fall har driftstödhante- raren ansvar för att villkoret uppfylls. Om driftstödhanteraren ignorerar detta ansvar förkastar det hanterade systemet uppdate- ringstransaktionen. Det andra sättet att uppfylla slutvillkoret är att låta det hanterade systemet vidmakthålla begränsningarna genom att automatiskt genomföra nödvändiga uppdateringar.A final condition can be met in either of two ways. Operation- the support system updates the managed system in such a way that the final conditions are maintained. In this case, the operating aid responsible for ensuring that the condition is met. About the operating support manager ignores this responsibility, the managed system rejects the update the ring transaction. The second way to meet the final condition is to allow the managed system to maintain the constraints by automatically making the necessary updates.

I det första fallet bestäms strategin av driftstödhanteraren utifrån driftstödsinformationsmodellspecifikationen, från vilken det är bestämbart vilka operationer som i det föreliggande tillståndet är tillåtna. I det andra fallet utförs följdopera- tioner automatiskt av det hanterade systemet.In the first case, the strategy is determined by the operations support manager based on the operational support information model specification, from which it is determinable which operations are in the present the condition is allowed. In the second case, sequential operations are performed automatically by the managed system.

I exemplet enligt fig. 34 kan endera av dessa strategier övervägas. Om attributet Line töms och AdmState=unlocked skulle Admstate kunna sättas till locked. Slutvillkoret i detta exempel förhindrar emellertid denna andra strategi. Den första strategin måste därför väljas. Slutvillkoret kontrolleras innan uppdate- ringstransaktionen av det hanterade systemet commitas och drift- stödsystemet får sålunda ta över ansvaret för att uppfylla villkoret. Rad 124,125 i fig. 35 visar hur detta kan uttryckas.In the example of Fig. 34, either of these strategies considered. If the Line attribute is cleared and AdmState = unlocked would Admstate can be set to locked. The final condition in this example however, prevents this second strategy. The first strategy must therefore be selected. The final condition is checked before updating the transaction of the managed system is committed and the support system may thus take over the responsibility for fulfilling the condition. Row 124,125 in Fig. 35 shows how this can be expressed.

Rad 134 i fig. 36 visar hur den andra strategin skulle kunna specificeras så att det hanterade systemet vidmakthåller sin konsistens.Row 134 in Fig. 36 shows how the second strategy could specified so that the managed system maintains its texture.

Hittills har endast slutvillkor, som reglerar konsistensbe- gränsningarna inuti ett objekt diskuterats. Man måste emellertid också kunna ange slutvillkor som specificerar konsistensbegräns- ningar mellan objekt.To date, only final conditions, which regulate consistency the boundaries within an object are discussed. One must, however also be able to specify final conditions that specify consistency between objects.

I fig. 37 specificeras objektet LineDriver. Detta objekt har en relation till objektet Subscriber i fig. 33. Ett slutvillkor 470 456 49 som reglerar konsistensbegränsningen mellan de två objekten måste nu kunna specificeras. På rad 118 i fig. 34 och rad 163 i fig. 37 specificeras att de två objekten utgör del av samma beroendeschema LineAndSubscriber. Detta beroendeschema visas i fig. 38. Beroendeschemat i fig. 38, rad 169-171 anger att om Subscriber är låst så måste LineDriver vara låst.Fig. 37 specifies the object LineDriver. This item has a relation to the object Subscriber in Fig. 33. A final condition 470 456 49 which regulates the consistency limitation between the two objects must now be able to be specified. On row 118 in Fig. 34 and row 163 in Fig. 37 specifies that the two objects form part of the same dependency scheme LineAndSubscriber. This dependency scheme is shown in Fig. 38. The dependency diagram in Fig. 38, lines 169-171 indicates that if Subscriber is locked, so LineDriver must be locked.

Här följer nu en närmare beskrivning av hur definiering av inträtt tillstånd efter en operation sker.Here now follows a more detailed description of how the definition of entered condition after an operation takes place.

En del av lösningen på problemet att kunna bestämma det nya tillståndet hos ett hanterat system efter slutförandet av en operation utgör den ovan beskrivna användningen av slutvillkor tillsammans med reglerna för strategier för att vidmakthålla dessa villkor.Part of the solution to the problem of being able to decide the new the state of a managed system after the completion of a operation constitutes the use of final conditions described above together with the rules for sustainability strategies these terms.

Ett problem kvarstår emellertid, nämligen hur man bestämmer konsekvenserna av metoder och skapa-operationer. För detta ända- mål expanderas - och ändras något - begreppet slutvillkor genom att möjliggöra bindning av slutvillkoren till metoder och skapa- operationer.However, one problem remains, namely how to decide the consequences of methods and create operations. To this end, goals, the concept of final terms is expanded - and changed somewhat - by to enable the final conditions to be linked to methods and operations.

I det föreliggande exemplet, med abonnenten, har ett för- villkor definierats, som anger att AdmState måste vara låst som förutsättning för att acceptera att driftstödhanteraren tömmer attributet Line. Driftstödhanteraren bör kunna veta hur AdmState skall göras låst, eftersom attributet AdmState endast läses.In the present example, with the subscriber, a conditions defined, which indicates that AdmState must be locked as condition for accepting that the operating support manager empties attribute Line. The Operational Support Manager should know how to AdmState should be locked, as the AdmState attribute is read only.

Metoden LockRequest är i själva verket den metod som skall användas för att uppnå den önskade effekten.The LockRequest method is in fact the method that should be used to achieve the desired effect.

Fig. 39 visar på raderna 176-178 hur detta specificeras.Fig. 39 shows on lines 176-178 how this is specified.

Skillnaden mellan dessa slutvillkor och de slutvillkor, som är bundna till klasserna av styrda objekt - individuella eller grupper - är att villkoret alltid vidmakthålls av det hanterade systemet.The difference between these final conditions and the final conditions, which are bound to the classes of controlled objects - individual or groups - is that the condition is always maintained by the managed the system.

I fig. 40 visas ett annat fall där det specificeras att efter det objektet skapats är attributet Line ej lika med NULL. Efter- som attributet Line är ett referensattribut till ett annat objekt, är det bestämbart från specifikationen att abonnentob- jektet självt skapar - eller finner på annat sätt - ett objekt Linebriver och låter attributet Line hänvisa till detta objekt.Fig. 40 shows another case where it is specified that after the object created is the Line attribute not equal to NULL. After- as the Line attribute is a reference attribute of another object, it is determinable from the specification that the subscriber the project itself creates - or finds in another way - an object Linebriver and lets the attribute Line refer to this object.

Här följer nu en närmare beskrivning av hur en bestämbar driftstödmodell specificeras och implementeras. Härvid kommer det redan ovan i annat sammanhang nämnda språket C++ till an- T ¶ i 11:» Q 50 vändning.Here now follows a more detailed description of how a determinable operational support model is specified and implemented. Here comes the the language already mentioned in another context C ++ to T ¶ in 11: » Q 50 turn.

En driftstödmodell innehåller objekt och relationer. Detta åskådliggörs av fig. 41, där fyra objekttyper visas, vilka är relaterade till varandra antingen direkt eller indirekt. I en sådan modell föreligger det ofta konsistensbegränsningar och beroenden mellan objekten. I fig. 41 är exempelvis ett Trunk-ob- jekt 200 beroende av tillståndet hos sitt relaterade Port-objekt 202 för att kunna fungera. När således ett attribut (opstate) för operationstillståndet i ett Port-objekt avaktiveras bör även Trunk-objektet avaktiveras. Dessutom föreligger det ett liknande beroende mellan administrativt tillstånd, attributet admState i Trunk- och Port-objekten. Liknande beroenden kan tillämpas även på de andra relationerna i fig. 41.An operational support model contains objects and relationships. This is illustrated by Fig. 41, where four object types are shown, which are related to each other either directly or indirectly. In a such a model, there are often consistency limitations and dependencies between the objects. In Fig. 41, for example, a Trunk 200 depending on the state of its related Port object 202 to be able to function. Thus, when an attribute (update) for the operating state of a Port object should also be disabled The trunk object is disabled. In addition, there is a similar one depending on administrative state, attribute admState in Trunk and Port objects. Similar dependencies can also be applied on the other relations in Fig. 41.

För att kunna göra en driftstödinformationsmodell bestämbar bör det vara möjligt att klart ange sådana beroenden. Då kan ett driftstödsystem förutsäga konsekvenserna av en viss uppdate- ringsoperation i ett hanterat system.To be able to make an operating support information model determinable it should be possible to clearly state such dependencies. Then one can operating support systems predict the consequences of a certain operation in a managed system.

Implementering av sådana beroenden i de olika tillämpningar- na, som accessar databasen, leder till svårigheter i att under- hålla tillämpningarna och kan inte garantera databasens konsis- tens. Därför bör mekanismer för bevarande av beroenden och konsistensbegränsningar implementeras i databassystemet. Logiken för att upprätthålla konsistensregler avseende information lagrad i databasen bör alltså bilda del av logiken hos databasen snarare än de databasen accessande tillämpningarna. På detta sätt specificeras och implementeras varje regel endast på ett ställe.Implementation of such dependencies in the various applications , which access the database, leads to difficulties in maintain the applications and cannot guarantee the consistency of the database tens. Therefore, mechanisms for the preservation of dependencies and consistency constraints are implemented in the database system. The logic to maintain consistency rules regarding information stored in the database should thus form part of the logic of the database rather than the database accessing applications. On this each rule is specified and implemented in one way only place.

Här skall nu inledningsvis en rekapitulation av tillämpliga delar av vad som tidigare beskrivits med avseende på uppfin- ningen och dess olika aspekter, jfr särskilt fig. 3 och 4 och motsvarande textställen, ges med hänvisning till de i fig. 42-44 visade block- och funktionsschemana.Here shall now initially be a recapitulation of applicable parts of what has been previously described with respect to the invention and its various aspects, cf. in particular Figures 3 and 4 and corresponding text passages, are given with reference to those in Figs. 42-44 showed block and function diagrams.

Driftstödinformationsmodellen av ett hanterat system 204 består av en uppsättning styrda objekt 206 med attribut, meto- der, notifikationer, relationer och konsistensregler. De flesta av dessa objekt implementeras bl.a. med DOL-logik (Database Object Logic) och persistenta databasobjekt. Många styrda objekt (sådana som representerar en hårdvaruresurs) innehåller även en statisk process 208, jfr fig. 42, för att accessa och mottaga 470 456 51 signaler från den fysiska anordning objektet representerar.The operational support information model of a managed system 204 consists of a set of controlled objects 206 with attributes, methods notifications, relationships and consistency rules. Most of these objects are implemented i.a. with DOL logic (Database Object Logic) and persistent database objects. Many controlled objects (those representing a hardware resource) also contains one static process 208, cf. Fig. 42, for accessing and receiving 470 456 51 signals from the physical device the object represents.

Databasobjekten kan emellertid innehålla data, som accessas från trafiktillämpningar och ej är synliga i driftstödsystemets vy av objektet. De styrda objekten implementeras i själva verket ofta ej som verkliga objekt, utan snarare utgör de just vyer 210 av verkliga implementerade objekt. De verkliga objekten 206 kan betraktas som resursobjekt. Ett resursobjekt är sålunda ett objekt som innehåller funktionalitet för både driftstöd och tra- fikstöd, jfr fig. 42.However, the database objects may contain data that is accessed from traffic applications and are not visible in the operating support system view of the object. The controlled objects are in fact implemented often not as real objects, but rather they constitute just views 210 of real implemented objects. The actual objects 206 can considered as a resource object. A resource object is thus one objects that contain functionality for both operational support and fixed support, cf. Fig. 42.

Varje resursobjekt 206 innehåller en uppsättning operationer, som bildar en driftstödvy av objektet. Den generiska agenten 212 accessar driftstödvyn av respektive objekt. Dessa driftstödvyer bildar tillsammans driftstödinformationsmodellen 214. Denna modell 214 är sålunda en vy av den underliggande fullständiga informationsmodellen 216.Each resource object 206 contains a set of operations, which forms an operating support view of the object. The generic agent 212 accesses the operating support view of each object. These operating support views together form the operational support information model 214. This model 214 is thus a view of the underlying complete the information model 216.

Varje hanterat objekt är av en särskild typ. Objekttypen definierar egenskaper gemensamma för alla objekt av denna typ, d.v.s. attribut, metoder, relationer och konsistensregler. För varje objekttyp finns det en resursagent 218 (fig. 44), som innehåller logiken för denna objekttyp. Varje instans av en objekttyp representeras av ett databasobjekt 220, som innehåller instansens persistenta datavärden. För varje styrt objekt finns det sålunda en resursagent 218 och ett databasobjekt 220 (till- sammans med bl.a. statiska processer).Each managed item is of a specific type. Object type defines properties common to all objects of this type, i.e. attributes, methods, relationships and consistency rules. For for each object type there is a resource agent 218 (Fig. 44), which contains the logic of this object type. Each instance of a object type is represented by a database object 220, which contains the persistent data values of the instance. For each controlled object is available thus, a resource agent 218 and a database object 220 (supplied together with i.a. static processes).

Detta framgår av fig. 44. Den generella agenten 212 accessar resursagenten 218 via MOSI-gränssnittet 222 (Managed Object Service Interface). Detta gränssnitt terminerar operationer definierade i driftstödsinformationsmodellen. Resursagenten 218 är instansierad till en objektinstans. Resursagentens DOL-logik 224 accessar instansens databasobjekt via ett DMI-gränssnitt 226 (Database Management Interface).This is shown in Fig. 44. The general agent 212 accesses the resource agent 218 via the MOSI interface 222 (Managed Object Service Interface). This interface terminates operations defined in the operational support information model. Resource Agent 218 is instantiated to an object instance. Resource Agent DOL Logic 224 accesses the instance's database objects via a DMI interface 226 (Database Management Interface).

Lösningen innebär visst maskintolkningsbart språk för att specificera persistenta objekt med egenskaper - fastställda inom områdena för konceptuell modellering och objektorientering - såsom attribut, metoder och relationer, och innefattar även ovan beskrivna slut- och förvillkor.The solution involves some machine-interpretable language to specify persistent objects with properties - determined within the areas of conceptual modeling and object orientation - such as attributes, methods and relationships, and also includes the above described end and preconditions.

I den nedanstående beskrivningen och närmare förklaringen av för- och slutvillkoren används bl.a. syntax, som ej utgör del av något existerande språk, utan endast används här för att klar- s _? I .f Û 43:-. (fl 52 göra principerna med hjälp av exempel. Här använd pseudo-syntax framgår av de tidigare beskrivna figurerna 30-40 och av fig. 45.In the description below and in more detail the explanation of the pre- and final conditions are used i.a. syntax, which does not form part of any existing language, but is only used here to clarify s _? IN .f Û 43: -. (fl 52 make the principles using examples. Use pseudo-syntax here can be seen from the previously described Figures 30-40 and from Figure 45.

Nedanstående beskrivning upprepar delvis det som sagts ovan med hänvisning till fig. 30-40, ehuru mera generaliserat.The description below partly repeats what has been said above reference to Figs. 30-40, although more generalized.

Exemplet i fig. 45 specificerar en objekttyp benämnd Anobject, rad 1. Den innehåller tre persistenta attribut: attrl, attrz och attr3 (d.v.s. attribut vilkas värden är lagrade i en databas). De typer av värden som dessa attribut kan acceptera är Atype, Integer resp. Integer, 4-6. Vidare innehåller Anobject två metoder, benämnda m1 och m2. Dessa metoder har vardera ett argument av typerna ArgType resp. AnotherArgType,raderna 9-10.The example in Fig. 45 specifies an object type named Anobject, row 1. It contains three persistent attributes: attrl, attrz and attr3 (i.e. attributes whose values are stored in a database). The types of values that these attributes can accept are Atype, Integer resp. Integer, 4-6. Furthermore, Anobject contains two methods, called m1 and m2. These methods each have one arguments of the types ArgType resp. AnotherArgType, lines 9-10.

Metoden m2 returnerar ett värde av typen AreturnType, rad 10.The m2 method returns a value of type AreturnType, line 10.

Vidare har AnObject i fig. 45 ett förvillkor som specificerar att värdet hos attr2 måste vara lika med värdet hos attr3 när metoden ml skall exekveras, rad 13. Slutvillkoret anger att värdet på attr2 alltid måste vara större än eller lika med värdet på attr3, rad 16. Det är en begränsning, som ej får överträdas när en transaktion utförts på databasen.Furthermore, AnObject in Fig. 45 has a precondition specifying that the value of attr2 must be equal to the value of attr3 when method ml shall be executed, line 13. The final condition states that the value of attr2 must always be greater than or equal to the value of attr3, line 16. It is a constraint, which must not violated when a transaction is performed on the database.

Objekttypen AnObject i fig. 45 visar enkla exempel på för- och slutvillkor. Något mer komplicerade exempel på slutvillkor föreligger när villkoret avser flera relaterade objekttyper.The object type AnObject in Fig. 45 shows simple examples of and final terms. Slightly more complicated examples of final terms exists when the condition refers to several related object types.

Detta kan åskådliggöras med ett exempel, som inbegriper två objekttyper: ResourceA och Resourceß (beroendena mellan dessa objekt är i stor utsträckning liknande beroendena mellan Trunk och Port i fig. 41).This can be illustrated by an example, which includes two object types: ResourceA and Resourceß (the dependencies between these objects are largely similar to the dependencies between Trunk and Port in Fig. 41).

Med hänvisning till fig. 46, som visar specifikationen för ResourceA, innehåller denna objekttyp två tillståndsattribut: admstate och opstate. Attributet admstate anger huruvida ett objekt är i drift eller inte, rad 23, medan opstate å andra sidan anger huruvida objektet är funktionsdugligt eller inte,rad 24. Det finns även ett s.k. referensattribut Bref. Sådana refe- rensattribut implementerar databasrelationer mellan objekt. Alla instanser av ResourceA i databasen kommer att innehålla en refe- rens till sin relaterade ResourceB-instans i attributet Bref, rad 25.Referring to Fig. 46, which shows the specification for ResourceA, this object type contains two state attributes: admstate and uppsate. The admstate attribute indicates whether one objects are in operation or not, line 23, while opgate on the other the page indicates whether the object is functional or not, line 24. There is also a so-called reference attribute Letter. Such references cleaning attributes implement database relationships between objects. All instances of ResourceA in the database will contain a reference to its related ResourceB instance in the Letter attribute, rad 25.

Förvillkoret i fig. 46 anger att för avlägsnande av en instans av ResourceA måste admstate vara lika med locked (vilket anger att objektet ej används), rad 32. Slutvillkoret i fig. 46 anger att en instans av ResourceA kan endast vara i drift Pa -:1 f: 4:»- m o\ 53 (admstate = unlocked) om den är relaterad till ett ResourceB- objekt, rad 35.The precondition in Fig. 46 indicates that for the removal of a instance of ResourceA, admstate must be equal to locked (which indicates that the object is not in use), line 32. The final condition in Fig. 46 indicates that an instance of ResourceA can only be in operation Pa -: 1 f: 4: »- m O\ 53 (admstate = unlocked) if it is related to a ResourceB object, row 35.

Specifikationen av Resourceß återfinns i fig. 47. Bl.a. innehåller den ett referensattribut, Aref, som utgör inversen av Bref i ResourceA, rad 45. Såsom framgår av fig. 47 har ResourceB samma förvillkor som ResourceA, rad 52.The specification of Resourceß can be found in Fig. 47. Among other things. it contains a reference attribute, Aref, which is the inverse of Letter in ResourceA, line 45. As shown in Fig. 47, ResourceB same conditions as ResourceA, line 52.

Som nämnts ovan finns det slutvillkor som avser både ResourceA och ResourceB. Dessa slutvillkor kan betraktas som beroenden mellan de två två objekttyperna. Ett sådant beroende avser ett delsystem innehållande flera objekttyper.As mentioned above, there are final terms that apply to both ResourceA and ResourceB. These final terms can be considered as dependencies between the two two object types. Such an addiction refers to a subsystem containing several object types.

I fig. 48 specificeras ett beroendeschema, som specificerar slutvillkor avseende ResourceA och ResourceB. Det första villko- ret anger att ett objekt av typ ResourceA ej kan vara "unlocked" om dess relaterade ResourceB-objekt är "locked", raderna 62 och 63. Det andra villkoret anger att om värdet hos opstate i ett ResourceB-objekt är avaktiverat får inte värdet hos opState i motsvarande ResourceA-objekt var aktiverat, raderna 65 och 66.Fig. 48 specifies a dependency diagram which specifies final terms regarding ResourceA and ResourceB. The first condition the item indicates that an object of type ResourceA can not be "unlocked" if its related ResourceB object is "locked", lines 62 and 63. The second condition states that if the value of uppsate in one ResourceB object is disabled does not get the value of opState i corresponding ResourceA object was enabled, lines 65 and 66.

I fig. 49 visas en begreppsmodell, som åskådliggör relationer mellan slut-/förvillkor och de koncept på vilka de är tilllämp- bara. Fig. 49 torde tala för sig själv utan närmare förklaring av de enskilda blocken.Fig. 49 shows a conceptual model which illustrates relations between the final / preconditions and the concepts to which they apply only. Fig. 49 should speak for itself without further explanation of the individual blocks.

Semantiken hos för- och slutvillkoren måste vara klar och otvetydig. Här skall nu exakta definitioner av dessa koncept ges. Ett slutvillkor specificeras i en driftstödinformations- modell. Slutvillkoret anger en statisk konsistensregel, som ej får överträdas i ett hanterat system, som är anpassat till driftstödinformationsmodellen. Närmare bestämt är ett slutvill- kor tillämpbart på databasen i det hanterade systemet. Ett slutvillkor avser objektinstanser och deras attributvärden, som lagras i databasen, jfr fig. 49.The semantics of the pre- and final terms must be clear and unambiguous. Here are now exact definitions of these concepts ges. A final condition is specified in an operating aid information model. The final condition specifies a static consistency rule, which does not may be violated in a managed system, which is adapted to the operational support information model. More specifically, a final applicable to the database in the managed system. One final conditions refer to object instances and their attribute values, such as stored in the database, cf. Fig. 49.

Såsom nämnts tidigare kan ett slutvillkor exempelvis ange ett beroende mellan attributvärden. Ett annat exempel är kardinaliteten mellan attribut och databasrelationer, d.v.s. begränsningar med avseende på antalet värden hos ett attribut.As mentioned earlier, a final condition can, for example, specify one dependence between attribute values. Another example is the cardinality between attributes and database relations, i.e. restrictions on the number of values of an attribute.

Det kan även finnas begränsningar med avseende på antalet in- stanser av en objekttyp.There may also be restrictions on the number of stops an object type.

En databas, som måste vara anpassad till ett visst slutvill- kor, som anger en viss begränsning, får sålunda aldrig övergå i ett tillstånd, som strider mot denna begränsning. Tillstånds- 4 % . f? / Ü 54 övergångar hos databaser uppträder när operationer uppdaterar lagrad information.A database, which must be adapted to a certain final condition cows, which indicate a certain limitation, must thus never pass into a condition which is contrary to this restriction. Conditional 4 % . f? / Ü 54 Database transitions occur when operations update stored information.

Uppdateringsoperationer utförs i transaktioner. En trans- aktion består av en följd av operationer. Transaktionen kan emellertid betraktas såsom varande atomisk, på så sätt att antingen alla operationer eller ingen utförs. Detta åstadkoms genom commit- och tillbakarullningsoperationer. Transaktionen utförs endast om varje operation är lyckad. Om något går fel under transaktionen rullas den annars tillbaka (d.v.s. alla operationer är ogjorda).Update operations are performed in transactions. A trans- action consists of a sequence of operations. The transaction can however, is considered to be atomic, in that way either all operations or none are performed. This is accomplished through commit and rollback operations. The transaction performed only if each operation is successful. If something goes wrong during the transaction it is otherwise rolled back (i.e. all operations are undone).

Det måste sålunda garanteras att databasen intar ett konsis- tent tillstånd när en transaktion är slutförd. En transaktion behandlar endast kopior av dataobjekten och de verkliga objekten uppdateras ej innan transaktionen commitas. Detta betyder att brytning mot konsistensreglerna kan temporärt ske under trans- aktionen. När transaktionen skall commitas får emellertid ingen brytning ske mot begränsningar.It must therefore be ensured that the database maintains a consistent condition when a transaction is completed. A transaction only processes copies of the data objects and the real objects is not updated before the transaction is committed. This means that violation of the consistency rules may temporarily occur during the action. However, when the transaction is to be committed, no one gets breaking takes place against restrictions.

Ett förvillkor anger en regel, som måste vara uppfylld när en särskild operation skall utföras, jfr fig. 49. Närmare bestämt måste databasen befinna sig i tillstånd där regeln är uppfylld innan transaktionen börjar.A precondition indicates a rule, which must be fulfilled when one special operation must be performed, cf. Fig. 49. More specifically the database must be in a state where the rule is met before the transaction begins.

Förvillkor kan exempelvis användas för att begränsa opera- tionsordningen på databasen. Begränsningar av tillståndsöver- gångar kan även uttryckas.Conditions can be used, for example, to limit the system on the database. Restrictions on permit transfer times can also be expressed.

Här följer nu en närmare beskrivning av hur implementerings- mekanismer kan specificeras.Here is a more detailed description of how the implementation mechanisms can be specified.

Vad avser slutvillkor finns det, som tidigare beskrivits, två alternativa principer för implementering. Ett alternativ är kon- sistenskontroller i transaktioner, som exekveras innan tran- saktionen commitas. Endast om inget slutvillkor överträds com- mittas transaktionen, annars rullas den tillbaka.As for final terms, there are, as previously described, two alternative principles for implementation. An alternative is con- checks in transactions, which are executed before the the action is committed. Only if no final condition is violated the transaction is centered, otherwise it is rolled back.

Den andra alternativa lösningen är automatiska korrigerings- åtgärder. Detta kan genomföras med triggade operationer. Närmare bestämt triggas operationerna vid vissa tillfällen, exempelvis när ett visst attribut har uppdaterats. specifikationerna i fig. 50 åskådliggör hur båda dessa alternativa implementeringsmekanismer kan specificeras. Det första slutvillkoret - avseende attributet admstate i respektive objekt - specificeras för implementering med konsistenskontrol- 470 456 55 ler innan transaktionerna committas, rad. 73-77.The second alternative solution is automatic correction measures. This can be done with triggered operations. Closer the operations are definitely triggered at certain times, for example when a certain attribute has been updated. the specifications of Fig. 50 illustrate how both of these alternative implementation mechanisms can be specified. The first end condition - regarding the attribute admstate in the respective objects - specified for implementation with consistency control 470 456 55 before the transactions are committed, line. 73-77.

Det andra slutvillkoret specificeras för att delvis genomför- as med automatiska korrektioner. När opState i ResourceB till- delas avaktiverad propageras operationen till opState i ResourceA. När opState i ResourceB tilldelas aktiverad måste emellertid en konsistenskontroll ske, raderna 79-79.The second final condition is specified to be partially implemented as with automatic corrections. When opState in ResourceB if disabled, the operation is propagated to opState i ResourceA. When opState in ResourceB is assigned must be enabled however, a consistency check is done, lines 79-79.

Om en helt automatisk implementering av slutvillkoren i fig. 50 önskas är implementeringen något mer komplicerad. Attributet opState i ResourceA kan betraktas som ett härledningsbart attri- but, som beror både av det interna tillståndet hos ResourceA och tillståndet i Resourceß. Fig. 51 åskådliggör hur opstate i ResourceA kan specificeras som ett härlett attribut, raderna 92- 95. Värdet hos opstate kalkyleras från värdena hos två andra attribut: internalOpState och ResourceBstate. Attributet Resour- ceBstate är en mappning av opState i ResourceB. Varje gång värdet på opstate i Resourceß-objektet ändras bör det således propageras vidare till ResourceBstate i det relaterade ResourceA-objektet, raderna 117,118. Detta kan specificeras i beroendeschemat för ResourceAandB visat i fig. 52.If a completely automatic implementation of the final conditions in fig. 50 is desired, the implementation is somewhat more complicated. The attribute opState in ResourceA can be considered a derivable attribute but, which depends on both the internal state of ResourceA and the state of Resourceß. Fig. 51 illustrates how uppate in ResourceA can be specified as a derived attribute, lines 92- 95. The value of upstate is calculated from the values of two others attributes: internalOpState and ResourceBstate. Resource attribute ceBstate is a mapping of opState in ResourceB. Each time the value of update in the Resourceß object should therefore change propagated further to ResourceBstate in the related ResourceA object, rows 117,118. This can be specified in the dependency scheme for ResourceAandB shown in Fig. 52.

Här följer nu en närmare beskrivning av hur mekanismerna för upprätthållande av slut- och förvillkoren kan implementeras i C++. Implementeringen kan genereras automatiskt från de ovan nyss beskrivna specifikationerna för implementeringsmekanismer.Here is a more detailed description of how the mechanisms work maintenance of the final and preconditions can be implemented in C ++. The implementation can be generated automatically from the above the specifications just described for implementation mechanisms.

Först skall slutvillkoren behandlas.First, the final terms must be considered.

Implementeringen av konsistenskontroller kompileras in i respektive objekttyp. Detta betyder att varje objekt är i stånd att kontrollera alla begränsningar som avser objektet. Konsi- stenskontrollerna i ett objekt skall utföras varje gång en transaktion har manipulerat objektet, innan transaktionen com- mitas.The implementation of consistency checks is compiled into respective object type. This means that each object is in condition to check all restrictions relating to the object. Consi- the stone checks in an object must be performed every time one transaction has manipulated the object, before the transaction mitas.

I fig. 53 visas transaktionens faser. Först utförs alla operationer, enligt 250. Därefter måste alla objekt som manipu- lerats utföra en konsistenskontroll, enligt 252. Om ingen kon- sistensbegränsning överträds slutförs transaktionen, 254, annars rullas den tillbaka, 256. Alla uppdateringsoperationer måste vara gjorda innan konsistenskontrollerna utförs.Fig. 53 shows the phases of the transaction. First, all are performed operations, according to 250. Thereafter, all objects which are performed a consistency check, according to 252. If no last limit is violated, the transaction is completed, 254, otherwise rolled back, 256. All update operations must be made before the consistency checks are performed.

För att visa den automatiskt genererade implementeringen av konsistenskontroller kan exemplet i fig. 46 användas. Om inga regler för upprätthållande av ett visst slutvillkor specificeras .. ' fí-"ÉÛ i? o 01 56 skall implementationen vid default utföra en konsistenskontroll.To display the automatically generated implementation of consistency checks, the example in Fig. 46 can be used. If none rules for maintaining a certain final condition are specified .. ' fí- "ÉÛ i? o 01 56 the implementation shall by default perform a consistency check.

Slutvillkoret i ResourceA i fig. 46 skulle således implementeras med en konsistenskontroll. Den automatiskt genererade implemen- teringskoden visas i C++. Objekttypen ResourceA kompileras sålunda till en klass i C++. Deklarationsfilen för denna klass visas i fig. 54.Thus, the final condition of ResourceA in Fig. 46 would be implemented with a consistency check. The automatically generated implementation the display code is displayed in C ++. The object type ResourceA is compiled thus to a class in C ++. The declaration file for this class shown in Fig. 54.

Klassen i fig. 54 är i själva verket en implementering av en resursagent. Genom att anropa den statiska metoden öppna (rad 134), med ett värde på huvudnyckeln som parameter, kan denna resursagent instansieras till ett databasobjekt. För varje persistent attribut i resursobjektet (admState, opState och Bref), finns det både en skriv- och en läs- metod för att skriva och läsa värden på attributet i det databasobjekt, till vilket resursagenten är instansierad.The class in Fig. 54 is in fact an implementation of a resource agent. By calling the static method open (line 134), with a value of the master key as a parameter, this can resource agent is instantiated to a database object. For each persistent attributes in the resource object (admState, opState and Brief), there is both a writing and a reading method for writing and read values of the attribute of the database object to which the resource agent is instantiated.

Vad som i fig. 54 är av intresse i detta sammanhang är metoden i rad 137. Detta är en metod som anropas innan trans- aktionen committas för att kontrollera konsistensreglerna.What is of interest in this context in Fig. 54 is the method in line 137. This is a method called before the trans- the action is committed to check the consistency rules.

Implementeringen av denna metod återfinns i fig. 55. När det rör sig om slutvillkor avseende flera relaterade objekt (som i fig. 48), måste konsistenskontrollen utföras i varje objekt.The implementation of this method is found in Fig. 55. When it comes to is about final conditions regarding several related objects (as in fig. 48), the consistency check must be performed on each object.

Här skall nu triggade operationer och propageringar beskri- vas. .Here, triggered operations and propagations will now be described. vase. .

För att åskådliggöra hur implementeringen av automatiska korrektioner kan genereras kan vi använda specifikationen i fig. 50. Rad 82 anger att värdet på opState i ResourceB skall pro- pageras till opstate i ResourceA när opstate är tilldelat av- aktiverat. Deklarationsfilen hos ResourceB återfinns i fig. 56.To illustrate how the implementation of automatic corrections can be generated, we can use the specification in fig. 50. Line 82 indicates that the value of opState in ResourceB should be paged to uppate in ResourceA when the uppate is assigned by activated. The declaration file of ResourceB can be found in Fig. 56.

Vad som huvudsakligen är av intresse är metoderna set0pState och propagateOpState, raderna 198 respektive 203. Fig. 57 visar implementeringen av dessa metoder.What is mainly of interest are the methods set0pState and propagateOpState, rows 198 and 203, respectively. Fig. 57 shows the implementation of these methods.

Såsom framgår av fig. 57 anropas metoden propagate0pState i metoden set0pState när attributet opstate ändras från aktiverat till avaktiverat. Detta innebär att propagateOpState triggas vid tillståndsövergångar från aktiverat till avaktiverat. Denna triggade operation överför det nya värdet hos opstate till det relaterade ResourceA-objektet.As shown in Fig. 57, the method propagate0pState i is called the set0pState method when the update attribute changes from enabled to disabled. This means that propagateOpState is triggered state transitions from enabled to disabled. This triggered operation transfers the new value of upstate to it related ResourceA object.

Ett förvillkor är ett villkor som måste gälla när en viss operation skall utföras. I motsats till slutvillkor måste för- villkor bestämmas innan operationen i fråga utförs i transaktio- (X1 O\ 78 4~ 57 nen. Förvillkor kan sålunda knappast upprätthållas med auto- matiska korrigeringsåtgärder, varför de endast kan implementeras med konsistenskontroller. En annan skillnad i förhållande till slutvillkor är att förvillkor måste accessa de ursprungliga i databasen lagrade attributvärdena, i stället för kopian i trans- aktionen.A precondition is a condition that must apply when a certain operation must be performed. In contrast to final terms, conditions are determined before the operation in question is carried out in (X1 O\ 78 4 ~ 57 nen. Conditions can thus hardly be maintained with auto- corrective measures, so they can only be implemented with consistency checks. Another difference in relation to final condition is that precondition must access the original in the database stored the attribute values, instead of the copy in the the action.

I fig. 58 åskådliggörs algoritmen vid utförande av operatio- nerna i en transaktion. Såsom framgår av fig. 58, vid 260 rullas transaktionen tillbaka när ett förvillkor överträds.Fig. 58 illustrates the algorithm in performing the operation. in a transaction. As shown in Fig. 58, at 260 is rolled the transaction back when a precondition is violated.

I fig. 59 visas en deklarationsfil genererad från specifika- tionen i fig. 46. Specifikationen i fig. 59 innehåller en metod för värdering av förvillkoret avseende deleteøbject-operationen (rad 268). Denna metod skall triggas när de1eteObject-operatio- nen skall utföras.Fig. 59 shows a declaration file generated from the specification the specification in Fig. 46. The specification in Fig. 59 contains a method for evaluation of the precondition for the delete object project (row 268). This method should be triggered when the de1eteObject operation to be performed.

Fig. 60 visar den automatiskt generade implementationen av metoderna delete0bject och deleteObjectCondition i ResourceA. I delete0bject anropas metoden deleteObjectCondition innan objek- tet verkligen tas bort. Metoden deleteObjectCondition läser det i databasen lagrade värdet av admstate med metoden admStateDatabaseVa1ue. Om villkoret är att admstate måste låsas kastas en exception. När exception fångas rullas transaktionen tillbaka. Om å andra sidan villkoret gäller raderas objektin- stansen från databasen genom metoden reallyDelete, som anropas i deleteøbject.Fig. 60 shows the automatically generated implementation of the delete0bject and deleteObjectCondition methods in ResourceA. IN delete0bject is called the deleteObjectCondition method before object really removed. The deleteObjectCondition method reads it in the database stored the value of admstate with the method admStateDatabaseVa1ue. If the condition is that admstate must be locked cast an exception. When the exception is captured, the transaction is rolled back. If, on the other hand, the condition applies, the object the punch from the database by the reallyDelete method, called in deleteøbject.

Fördelarna med det ovan beskrivna är följande.The advantages of the above are as follows.

Implementeringskoden kan genereras automatiskt (kompileras) från samma klargörande specifikation, som tolkas av driftstöd- systemet. Modifikationer av specifíkationen av modellen kommer att automatiskt uppdatera både operatörens vy av informations- basen och implementationen av densamma. Det hanterade systemet kan därför garanteras att uppföra sig på det av driftstödsyste- met förutsagda sättet.The implementation code can be generated automatically (compiled) from the same clarifying specification, which is interpreted by the the system. Modifications to the specification of the model are coming to automatically update both the operator's view of the information the base and its implementation. It managed the system can therefore be guaranteed to behave on the part of the met the predicted way.

Varje konsistensbegränsning behöver endast specificeras en gång. Implementeringen inkapslas tillsammans med de i konsi- stensbegränsningen ingående attributen. Inga konsistenskontrol- ler behöver implementeras i de tillämpningar som accessar datat.Each consistency limit only needs to specify one walk. The implementation is encapsulated together with those in the stone limitation included in the attributes. No consistency checks need to be implemented in the applications that access the data.

Underhållet av koden förenklas därför avsevärt.The maintenance of the code is therefore considerably simplified.

Alla konsistensbegränsningar i ett system implementeras på ett likformigt sätt. Tillförlitlig kod genereras automatiskt. .ïms f? l n. ñ _ U = fås (j. 6 58 Implementeringsstrategin decentraliseras på så sätt att beroenden bevaras genom kommunikation mellan de inbegripna objekten. Det finns ingen centraliserad funktionalitet, som måste modifieras vid tillföring av nya objekttyper - med nya beroenden - till ett hanterat system.All consistency restrictions in a system are implemented on in a uniform manner. Reliable code is generated automatically. .ïms f? l n. ñ _ U = available (j. 6 58 The implementation strategy is decentralized in such a way that dependencies are maintained through communication between those involved the objects. There is no centralized functionality, as must be modified when adding new object types - with new ones dependencies - to a managed system.

De i en transaktion ingående objekten kan temporärt - före utförande av konsistenskontroller - befinna sig i ett inkonsi- stent tillstånd. Detta förenklar hanteringen av databasen på så sätt att ordningen för operationerna i en transaktion är mindre betydelsefull.The objects in a transaction can be temporarily - before performance of consistency checks - be in an inconsistency stent condition. This simplifies the management of the database on so way that the order of operations in a transaction is smaller significant.

Den här beskrivna lösningen underlättar implementering av beroenden mellan systemkomponenter, som utvecklas okoordinerat.The solution described here facilitates the implementation of dependencies between system components, which develop uncoordinated.

Det är till och med möjligt att tillämpa lösningen på systemkom- ponenter, som kompileras och laddas separat..It is even possible to apply the solution to system components, which are compiled and loaded separately.

Här kommer nu en närmare beskrivning av fallet okoordinerad implementering av systemkomponenter att ges.Here is a more detailed description of the case uncoordinated implementation of system components to be provided.

Ett hanterat system består av flera delsystem, närmare bestämt en systemplattform och ett antal tillämpningar. Dessa delsystem utvecklas okoordinerat och laddas separat.A managed system consists of several subsystems, more specifically determined a system platform and a number of applications. These subsystems are developed uncoordinated and loaded separately.

Vid utvecklande av en tillämpning - eller systemplattform - finns det bibliotek med återanvändbara komponenter. Dessa kompo- nenter skall införlivas och kombineras på olika sätt i de olika delsystemen.When developing an application - or system platform - there are libraries with reusable components. These components elements must be incorporated and combined in different ways in the different subsystems.

De ovan beskrivna två olika problemen har vissa egenskaper gemensamma. Det finns systemkomponenter, som utvecklas okoordi- nerat, men fortfarande finns det beroenden mellan komponenterna.The two different problems described above have certain characteristics common. There are system components, which develop uncoordinated but there are still dependencies between the components.

För att bevara sådana beroenden är det nödvändigt att komponen- terna skall kunna kommunicera med andra komponenter som utveck- las och t.o.m. laddas separat.In order to preserve such dependencies, it is necessary that the must be able to communicate with other components that read and t.o.m. charged separately.

Den nedan närmare beskrivna konstruktionsprocessen är an- vändbar i två olika sammanhang med liknande problem.The construction process described in more detail below is reversible in two different contexts with similar problems.

Det första problemet hänför sig till återanvändning av bibliotekskomponenter.The first problem relates to the reuse of library components.

Vid konstruktion av ett hanterat system finns det bibliotek med återanvändbara komponenter, som kan införlivas i objekten i det hanterade systemet. Såsom åskådliggörs i fig. 61 finns det först ett huvudbibliotek 260 innehållande komponenter med grund- funktionalitet, såsom M0stateComponent 262 och Workingstate- Component 264. Dessa komponenter innehåller tillståndsattribut 470 456 59 gemensamma för många olika typer av styrda objekt. Funktiona- liteten hos dessa grundkomponenter återanvänds av andra kompo- nenter med mer specialiserad funktionalitet. I trafikstödbiblio- teket 266 finns det t.ex. en StatePropagationComponent 268, som har förmågan att överföra tillståndsändringar i MOstateComponent 262 till relaterade beroende objekt 270.When designing a managed system, there is a library with reusable components, which can be incorporated into the objects of the managed system. As illustrated in Fig. 61, there are first a main library 260 containing components with basic functionality, such as M0stateComponent 262 and WorkingstateComponent Component 264. These components contain state attributes 470 456 59 common to many different types of controlled objects. Functional the quality of these basic components is reused by other components with more specialized functionality. In the traffic support library teket 266 there are e.g. a StatePropagationComponent 268, which has the ability to transfer state changes in MOstateComponent 262 to related dependent objects 270.

Det bör framhållas att komponenterna liksom de styrda ob- jekten antas implementerade i ett objektorienterat språk. Både komponenterna och de styrda objekten är sålunda verkligen objekt. Men komponenterna kan ej existera som identifierbara objekt för sig i en tillämpning. De kan endast bilda del av styrda objekt.It should be emphasized that the components as well as the controlled the project is assumed to be implemented in an object-oriented language. Both the components and the controlled objects are thus real object. But the components cannot exist as identifiable objects separately in an application. They can only form part of controlled objects.

Ett rättframt sätt att implementera komponenter, som är beroende av andra grundkomponenter, t.ex. komponenterna i fel- hanterings- och trafikstödbiblioteken i fig. 61, är att inklude- ra grundkomponenterna antingen genom arv eller aggregering.A straightforward way to implement components, that is depending on other basic components, e.g. the components of the fault handling and traffic support libraries in Fig. 61, is to include the basic components either by inheritance or aggregation.

Detta ger emellertid upphov till vissa problem. Detta beror på att flera komponenter, t.ex. FaultHandlingComponent 272 och ResourceManagementComponent 274, som ärver eller aggregerar samma grundkomponent, t.ex. M0stateComponent 262, kan ingå i samma styrt objekt Route 276, jfr fig. 62. Detta betyder att det kommer att finnas flera kopior av grundkomponenten i det styrda objektet, som kommer att ge upphov till konsistensproblem om grundkomponenten innehåller data, som är synlig utanför kompo- nenterna. Data hos MOstateComponent skall m.a.o. vara tillgäng- ligt för annan funktionalitet i det styrda objektet än de kompo- nenter i vilka M0stateComponent är inkluderad Det finns ett sätt att undvika det ovan beskrivna problemet.However, this gives rise to some problems. This is because that several components, e.g. FaultHandlingComponent 272 and ResourceManagementComponent 274, which inherits or aggregates the same basic component, e.g. M0stateComponent 262, may be included in the same controlled object Route 276, cf. Fig. 62. This means that it there will be several copies of the basic component of the controlled the object, which will give rise to consistency problems if the basic component contains data, which is visible outside the nenterna. Data at MOstateComponent shall m.a.o. be available- for other functionality in the controlled object than the components components in which M0stateComponent is included There is a way to avoid the problem described above.

Mostatecomponent bör inte ärvas eller aggregeras i komponenter som beror av denna komponent. Istället bör de beroende komponen- terna innehålla referensattribut till M0stateComponent. Sålunda kommer den senare att vara en egen komponent i de objekt i vilka den inkluderas. Komponenter som behöver accessa M0stateComponent kommer då var och en innehålla en referens till samma instans av MO-tillståndskomponenten, jfr fig. 63.Mostate component should not be inherited or aggregated into components which depends on this component. Instead, the dependent components contain reference attributes to M0stateComponent. Thus the latter will be a separate component in the objects in which it is included. Components that need to access M0stateComponent will then each contain a reference to the same instance of The MO state component, cf. Fig. 63.

Såsom nämnts tidigare kan en komponent, såsom ResourceManage- mentComponent 274 och FaultHandlingComponent 272 innehålla funktionalitet som triggas av tillståndsändringar i MOstateCom- ponent 262. Den senare måste därför vara i stånd att sända till- I (n íq f U 4 O 60 ståndsändringsmeddelanden till andra komponenter. Ett problem är emellertid att mottagarna av dessa meddelanden är okända vid konstruktion av MOstateComponent. MOstateComponent 262 måste på något sätt kunna kommunicera 280, 282 med en godtycklig senare uppträdande komponent, jfr fig. 64.As mentioned earlier, a component such as the ResourceManage mentComponent 274 and FaultHandlingComponent 272 contain functionality triggered by state changes in MOstateCom- component 262. The latter must therefore be able to send IN (n íq f U 4 O 60 status change notifications to other components. One problem is however, that the recipients of these messages are unknown at construction of MOstateComponent. MOstateComponent 262 must be on somehow be able to communicate 280, 282 with an arbitrary later occurring component, cf. Fig. 64.

Det andra problemet hänför sig till en skiktad systemarkítek- tur.The second problem relates to a layered system architecture lucky.

Ett hanterat system kan implementeras i en skiktad arkitekt- ur. Närmare bestämt finns det systemplattformar med grundfunk- tioner, som kan återanvändas av olika tillämpningar, jfr fig. 65. Systemplattformen 290 innehåller bl.a. olika slag av gemen- samma telekomtjänster. Tillämpningen kan sålunda delegera många uppgifter till systemplattformen. Systemplattformen 290 och tillämpningarna 292 laddas separat. Det måste vara möjligt att ladda en tillämpning och länka den till systemplattformen utan återladdning av plattformen.A managed system can be implemented in a layered architectural from. More specifically, there are system platforms with basic ions, which can be reused by various applications, cf. fig. 65. The system platform 290 contains i.a. different types of common the same telecom services. The application can thus delegate many information to the system platform. The system platform 290 and the applications 292 are loaded separately. It must be possible to load an application and link it to the system platform without reloading the platform.

Både systemplattformen 290 och tillämpningarna 292 innehåller styrda objekt. Objekten 294 och 296 i plattformen 290 kan ex- empelvis representera resurser, såsom växlar, överföringsvägar, trunkar etc. Objekten 298, 300 och 302,304 i tillämpningarna 292.1 resp. 292.2 kan vara relaterade till och samverka med resurserna i systemplattformen, jfr fig. 66. Ett objekt i en tillämpning kan delegera vissa uppgifter till ett objekt i systemplattformen. Objekt i tillämpningarna kan sålunda bero av relaterade objekt i systemplattformen för att kunna fungera.Both the system platform 290 and the applications 292 contain controlled objects. The objects 294 and 296 in the platform 290 can be for example, represent resources, such as switches, transmission paths, trunks etc. Objects 298, 300 and 302,304 in the applications 292.1 resp. 292.2 may be related to and interact with the resources in the system platform, cf. Fig. 66. An object in a application can delegate certain tasks to an object in the system platform. Objects in the applications can thus depend on related objects in the system platform in order to function.

Eftersom systemplattformen är känd vid utveckling av en till- lämpning är det inget problem att konstruera objekten i till- lämpningarna för kommunicering med objekten i systemplattformen.Since the system platform is known in the development of an application, it is no problem to construct the objects in the applications for communication with the objects in the system platform.

Som nämnts tidigare kan emellertid objekten i tillämpningarna vara beroende av objekten i systemplattformen. Detta innebär att objekt i systemplattformen bör vara i stånd att överföra till- ståndsändringar, såsom beskrivs tidigare ovan, till objekt i tillämpningarna. Detta innebär att objekten i plattformen bör kunna vara relaterade till och ta initiativ till att anropa objekt, som är okända vid konstruktion av plattformssystemet.As mentioned earlier, however, the objects in the applications be dependent on the objects in the system platform. This means that objects in the system platform should be able to transfer status changes, as described earlier above, to objects in applications. This means that the objects in the platform should be able to be related to and take the initiative to call objects, which are unknown in the construction of the platform system.

Ovan har två fall med liknande problem beskrivits. Här skall nu följa en beskrivning av hur dessa problem kan lösas.Above, two cases with similar problems have been described. Here shall now follow a description of how these problems can be solved.

Närmare bestämt är i vart och ett av de två fallen det verkliga problemet att konstruera ett objekt, som skall kunna 4-70 456 61 kommunicera med okända framtida objekt. Det måste vara möjligt för originalobjektet att vara relaterat till och samverka med ett okänt framtida objekt utan modifiering, eller t.o.m. om- laddning av originalobjektet.More specifically, in each of the two cases it is real problem to construct an object, which should be able to 4-70 456 61 communicate with unknown future objects. It must be possible for the original object to be related to and interact with an unknown future object without modification, or t.o.m. if- loading the original object.

Detta problem kan lösas med den i fig. 67 åskådligjorda konstruktionsprincipen. Originalobjektet 330 konstrueras för att samverka med ett abstrakt objekt 332. Det abstrakta objektet definierar ett gränssnitt bestående av oimplementerade metoder.This problem can be solved with that illustrated in Fig. 67 the principle of construction. The original object 330 is designed to interact with an abstract object 332. The abstract object defines an interface consisting of unimplemented methods.

Dessa är de metoder, som kan anropas av originalobjektet. Vid konstruktion av ett objekt 334 avsett att samverka med original- objektet måste det ärva det abstrakta objektet 332 och implemen- tera de ärvda metoderna. Vid samverkan med en okänd typ av objekt kommer originalobjektet 330 att betrakta detta såsom varande av nämnda abstrakt typ 332. Vid anrop av en metod defi- nierad i gränssnittet hos det abstrakta objektet 332 kommer anropet att delegeras till implementationen i det verkliga objektet 330 via sen bindning.These are the methods that can be called by the original object. At construction of an object 334 intended to cooperate with the original object, it must inherit the abstract object 332 and implement the inherited methods. In collaboration with an unknown type of object, the original object 330 will consider this as being of said abstract type 332. When calling a method defined niered in the interface of the abstract object 332 will the call to be delegated to the implementation in the real object 330 via late binding.

Undvikande av omladdning av originalobjektet vid laddning av de framtida objekten åstadkoms med dynamisk länkning.Avoid recharging the original object when loading the future objects are created with dynamic linking.

Fig. 68 åskådliggör hur den nyss beskrivna konstruktionen kan användas för konstruktion av grundläggande bibliotekskompo- nenter. M0stateComponent 340 är konstruerad för att kommunicera med objekt, som ärver ett abstrakt objekt: M0stateSubscriber 342. Detta abstrakta objekt definierar metoder, som MOstateCom- ponent anropar när en tillståndsändring uppträder. Om en kompo- nent skall prenumerera på tillståndsändringar i MOstateCompo- nent, måste den ärva Mostatesubscriber 342 och implementera svaret till de respektive tillståndsändringsnotifikationerna.Fig. 68 illustrates how the construction just described can be used for the construction of basic library components nenter. M0stateComponent 340 is designed to communicate with object, which inherits an abstract object: M0stateSubscriber 342. This abstract object defines methods, such as MOstateCom- ponent calls when a state change occurs. If a compo- subscriber shall subscribe to license changes in MOstateCompo- nent, it must inherit Mostatesubscriber 342 and implement the response to the respective permit change notifications.

Den prenumererande komponenten måste naturligtvis även ange sig själv som en prenumerant till MOstateComponent.Of course, the subscribing component must also be specified himself as a subscriber to MOstateComponent.

De med hänvisning till fig. 67 beskrivna konstruktionsprin- ciperna kan även användas för att konstruera objekt i en system- plattform för att samverka med tillämpningsspecifika objekt.The construction principles described with reference to Fig. 67 the principles can also be used to construct objects in a system platform for interacting with application-specific objects.

Detta åskådliggörs i fig. 69, där objektet PlatformObjekt1 350 är konstruerat att samverka med objekt 352 i tillämpningsystemen 354. Ett objekt i en tillämpning, som skall samverka med objek- tet Platformobjektl 350 måste ärva det abstrakta objektet In- terface0bject 356. Vidare föreligger det en databasrelation mellan Platform0bject 350 och Interface0bject 356. Detta innebär .n ,2Wfj !'f “tíu -JÛ »- 62 att objekten som ärver Interfaceobject 356 kan upprätta relatio- ner med Platformøbjectl 350. För att göra det möjligt att ladda tillämpningar utan omladdning av systemplattformen används dynamisk länkning.This is illustrated in Fig. 69, where the object PlatformObjekt1 350 is designed to interact with objects 352 in the application systems 354. An object in an application, which is to interact with the object Platform object 350 must inherit the abstract object In- terface0bject 356. Furthermore, there is a database relation between Platform0bject 350 and Interface0bject 356. This means .n , 2Wfj! 'F “Ten -JU »- 62 that the objects inheriting Interfaceobject 356 can establish relationships down with Platformøbjectl 350. To make it possible to load applications without reloading the system platform are used dynamic linking.

Ofta är ett objekt i ett tillämpningssystem tillståndsbe- roende av ett objekt i systemplattformen. Denna konstruktion gör det möjligt att implementera sådana tillståndsberoenden på väsentligen samma sätt som för objekt som är kända för varandra när de implementeras, såsom kommer att beskrivas i närmare detalj längre ned.Often an object in an application system is conditional depending on an object in the system platform. This construction does it is possible to implement such permit dependencies on essentially the same way as for objects that are known to each other when implemented, as will be described in more detail detail further down.

Beroenden mellan okoordinerade objekt kan specificeras och implementeras på väsentligen samma sätt som mellan koordinerade objekt, vilket har beskrivits tidigare ovan. Här skall samma exempel användas för att Visa konstruktionen och implementering- en av beroenden mellan okoordinerade objekt. Det antas emeller- tid här att objekttypen Resoureß tillhör ett plattformssystem.Dependencies between uncoordinated objects can be specified and implemented in essentially the same way as between coordinated objects, as described earlier above. Here shall be the same examples can be used to show the design and implementation one of the dependencies between uncoordinated objects. However, it is time here that the object type Resoureß belongs to a platform system.

Sålunda kan, med hänvisning till fig. 70, olika slag av objekt i olika tillämpningssystem relateras till och samverka med objek- tet ResourceB 370. Objekttypen ResourceB 370 är relaterad till User0bject 372 via en databasrelation. ResourceA 374 ärver User0bject 372 för att kunna relateras till Resourceß 370. I det följande kommer det att visas hur dessa objekt specificeras och implementeras. Härvid används samma pseudo-syntax som ovan.Thus, with reference to Fig. 70, different types of objects in different application systems are related to and interact with ResourceB 370. The object type ResourceB 370 is related to User0bject 372 via a database relation. ResourceA 374 inherits User0bject 372 to be able to relate to Resourceß 370. In it the following will show how these objects are specified and implemented. The same pseudo-syntax is used as above.

Specifikationen av objektet Resourceß återfinns i fig. 71.The specification of the object Resourceß can be found in Fig. 71.

Specifikationen innehåller två tillståndsattribut: admState och opState, en metod för att allokera instanser av Resourceß och ett förvillkor som säger att för att radering av ett Resourceß- objekt skall vara tillåten måste det låsas. Detta är väsentligen detsamma som tidigare. Den enda skillnaden är att i detta exempel är ResourceB relaterat till User0bject istället för ResourceA. Relationen upprättas via referensattributet userRef, rad 6.The specification contains two state attributes: admState and opState, a method for allocating instances of Resourceß and a precondition that states that in order to delete a Resourceß- objects must be allowed, it must be locked. This is essentially the same as before. The only difference is that in this example, ResourceB is related to User0bject instead of ResourceA. The relationship is established via the reference attribute userRef, row 6.

I fig. 72 specificeras objektet User0bject. Det innehåller tillståndsattributet admstate. Det kan emellertid noteras att detta attribut specificeras såsom varande rent virtuellt, rad 19. Detta innebär att User0bject i själv verket ej kommer att innehålla attributet admstate. Gränssnittet hos User0bject kommer emellertid att innehålla oimplementerade skriv- och läs- metoder för detta attribut. Den verkliga implementeringen av 470 456 63 dessa rent virtuella metoder kommer att uppträda i de resp. subtyperna av UserObject. Dessutom finns det ett annat attribut resourceßstate, vilket antas hålla värdet hos opState i det relaterade objektet ResourceB. Vidare har UserObject ett refe- rensattribut Bref, som användes för att upprätta relationer med objekt av typen Resourceß, rad 21.In Fig. 72, the object User0bject is specified. It contains the state attribute admstate. However, it can be noted that this attribute is specified as being purely virtual, line 19. This means that User0bject will not, in fact contain the admstate attribute. The interface of User0bject will, however, include unimplemented read and write methods for this attribute. The real implementation of 470 456 63 these purely virtual methods will appear in the resp. the subtypes of UserObject. In addition, there is another attribute resourceßstate, which is assumed to hold the value of opState in it related object ResourceB. Furthermore, UserObject has a reference cleaning attributes Letter, which was used to establish relationships with object of type Resourceß, row 21.

Ett beroendeschema, som specificerar slutvillkor, innefat- tande både objektet Userobject och objektet Resourceß återfinns i fig. 73. Det finns ett slutvillkor, raderna 29-31, som anger att admstate hos UserObject beror av admstate i Resourceß, på så sätt att ett objekt UserObject ej kan låsas upp om det relatera- de objektet ResourceB är låst.A dependency chart specifying final terms includes both the Userobject object and the Resourceß object are found in Fig. 73. There is a final condition, lines 29-31, which indicates that admstate at UserObject depends on admstate in Resourceß, on so way that an object UserObject can not be unlocked if it is related the object ResourceB is locked.

I fig. 73 specificeras det vidare att när ett värde på opState i ett objekt ResourceB ändras, skall det nya värdet propageras till den relaterade instansen av UserObject. Man kan lägga märke till skillnaden mellan specifikationen i fig. 73 och specifikationen i fig. 52. I fig. 73 finns det inget slutvillkor specificerat som avser opState, det anges endast att ändringar av opState i Resourceß bör propageras till attributet resourceßstate i UserObject, raderna 36 och 37. Detta innebär att alla subtyper av UserObject ej är nödvändigtvis opState- beroende av ResoureB, men varje subtyp av UserObject kan hantera opState-beroendet av ResoureB på sitt eget sätt.In Fig. 73 it is further specified that when a value of opState in an object ResourceB changes, the new value should propagated to the related instance by UserObject. You can notice the difference between the specification in Fig. 73 and the specification in Fig. 52. In Fig. 73 there is no final condition specified as referring to opState, it only indicates that changes of opState in Resourceß should be propagated to the attribute resourceßstate in UserObject, lines 36 and 37. This means that not all subtypes of UserObject are necessarily opState- depending on ResoureB, but each subtype of UserObject can handle the opState dependence on ResoureB in its own way.

I fig. 74 visas specifikationen av ResourceA. ResourceA specificeras såsom varande en subtyp av UserObject (rad 41).Fig. 74 shows the specification of ResourceA. ResourceA specified as being a subtype of UserObject (line 41).

Detta innebär att ResourceA ärver attributen, metoderna, vill- koren och propageringarna i UserObject. Alla de rent virtuella specifikationerna i UserObject måste specificeras och implemen- teras i ResourceA. Såsom framgår av fig. 67 härleds värdet på opState i ResourceA från attributen internalOpState och resour- ceBstate (som ärvs från UserObject), raderna 46-49.This means that ResourceA inherits the attributes, methods, conditions the cores and propagations in UserObject. All the purely virtual the specifications in UserObject must be specified and implemented teras and ResourceA. As shown in Fig. 67, the value of is derived opState in ResourceA from the attributes internalOpState and resour- ceBstate (inherited from UserObject), lines 46-49.

Såsom nämnts tidigare är implementationen väsentligen densam- ma som när objekten tillhör samma system. Skillnaden är att viss del av funktionaliteten hos det beroende objektet som använder ResourceB implementeras i UserObject. Såsom tidigare kan koden automatiskt genereras från specifikationerna av en kompilator.As mentioned earlier, the implementation is essentially the same. as when the objects belong to the same system. The difference is that certain part of the functionality of the dependent object that uses ResourceB is implemented in UserObject. As before, the code automatically generated from the specifications of a compiler.

Deklarationsfilen som genereras från specifikationen av UserO- bject i fig. 72 återfinns i fig. 75.The declaration file generated from the UserO specification The object in Fig. 72 is found in Fig. 75.

Metoden checkconsistency i UserObject kontrollerar beroendet 64 mellan admState-attributen, som anges i beroendeschemat i fig. 73. Implementationen av denna metod visas i fig. 76. För att kontrollera detta villkor måste värdet på admState i Userobject läsas. Detta förklarar varför det måste finnas en rent virtuell specifikation av admState i Userøbject, även om detta attribut i själva verket inte ingår i Userøbject.The checkconsistency method in UserObject checks the dependency 64 between the admState attributes, which are specified in the dependency diagram in FIG. 73. The implementation of this method is shown in Fig. 76. To check this condition must the value of admState in Userobject read. This explains why there must be a purely virtual specification of admState in Userøbject, even if this attribute in in fact is not included in Userøbject.

Deklarationsfilen som genereras av specifikationen av Resour- ceB i fig. 71 återfinns i fig. 77. Den är nästan densamma som i fig. 56. Implementationen av metoden propagateøpstate är dock något annorlunda, jfr. fig. 78. Det nya värdet propageras till attributet Resourceßstate i den relaterade UserObject-instansen. admState-beroendet mellan UserObject och ResourceB måste kon- trolleras vid uppdatering av objektet ResourceB liksom vid upp- datering av UserObject-instanser. Därför är detta villkor imple- menterat i metoden checkConsistency i ResourceB.The declaration file generated by the Resource specification ceB in Fig. 71 is found in Fig. 77. It is almost the same as in Figs Fig. 56. However, the implementation of the propagateøpstate method is somewhat different, cf. Fig. 78. The new value is propagated to the Resourceßstate attribute in the related UserObject instance. The admState dependency between UserObject and ResourceB must be is checked when updating the object ResourceB as well as when updating dating of UserObject instances. Therefore, this condition is mentored in the checkConsistency method in ResourceB.

Fig. 79 visar den deklarationsfil, som genereras från speci- fikationen av ResourceA. opState-beroendet av ResourceB imple- menteras genom härledning av värdet på opState från resourceBs- tate och internal0pState, jfr. fig. 80.Fig. 79 shows the declaration file generated from speci- the certification of ResourceA. opState dependence on ResourceB impl- by deriving the value of opState from resourceBs- tate and internal0pState, cf. Fig. 80.

Fördelarna med det ovan beskrivna är följande.The advantages of the above are as follows.

Beroenden och samverkan mellan okoordinerade objekt kan specificeras och implementeras på samma sätt som beroenden mellan objekt i samma delsystem. Detta innebär att de är synliga för och kan tolkas av ett driftstödsystem.Dependencies and interactions between uncoordinated objects can specified and implemented in the same way as dependencies between objects in the same subsystem. This means that they are visible for and can be interpreted by an operational support system.

Den ovan åskådliggjorda processen för upprätthållande av beroonden mellan okoordinerade objekt på ett styrt och synligt sätt underlättar implementering av en bestämbar driftstödmodell i en skiktad arkitektur.The process illustrated above for maintaining the dependence between uncoordinated objects on a controlled and visible way facilitates the implementation of a definable operational support model in a layered architecture.

Graden av återanvändbarhet av bibliotekskomponenter kan förbättras genom en hög grad av flexibilitet när det rör sig om kombinationer av komponenter.The degree of reusability of library components can enhanced by a high degree of flexibility when it comes to combinations of components.

Claims (105)

ef: 'wii C.) .ffs LN Ow. 65 Patentkrav.ef: 'wii C.) .ffs LN Ow. 65 Patent claims. 1. Driftstödsnät med minst ett driftstödsystem och minst ett hanterat system, för telekom- eller öppna system, varvid nämnda hanterade system innehåller fysiska och/eller logiska resurser, som av driftstödsystemet betraktas och hanteras som styrda objekt i form av databilder av resurserna, och varvid drift- stödsystemet för sina mot det hanterade systemet riktade opera- tioner utnyttjar en driftstödsinformationsmodell av det hantera- de systemet, vilken innehåller en till driftstödsystemets ar- betssätt anpassad beskrivning av alla styrda objekt, känneteck- nat av att driftstödnätet förutom det hanterade systemet in- nefattar en generell driftstödhanterare och en representation av driftstödsinformationsmodellen, där den generella hanterarens uppträdande under drift bestäms av denna modellrepresentation.Operating support network with at least one operating support system and at least one managed system, for telecom or open systems, said managed system containing physical and / or logical resources, which are considered by the operating support system and managed as controlled objects in the form of data images of the resources, and The operating support system for its operations directed towards the managed system uses an operating support information model of the managed system, which contains a description of all controlled objects adapted to the operation of the operating support system, characterized in that the operating support network in addition to the managed system includes a general operating support manager and a representation of the operating support information model, where the general manager's behavior during operation is determined by this model representation. 2. Driftstödnät enligt krav 1, kännetecknat av att represen- tationen av driftstödsinformationsmodellen är införd i det hanterade systemet och är tillgänglig för den generella hantera- ren.Operational support network according to claim 1, characterized in that the representation of the operational support information model is introduced in the managed system and is available to the general manager. 3. Driftstödnät enligt krav 1 eller 2, kännetecknat av att driftstödsinformationsmodellens specifikation är i form av en bestämbar representation av driftstödsinformationsmodellen, vilken senare definierar - vilka tillstånd av intresse från driftstödsynpunkt det hanterade systemet kan anta, - vilka operationer som kan accepteras av det hanterade systemet, j - vilka operationer som kan riktas mot ett hanterat system i ett visst tillstånd, samt slutligen - vilket tillstånd det hanterade systemet uppnår när det utsätts för en viss operation, varvid med en bestämbar representation avses att ovanstående definitioner skall kunna uttryckas i ett maskintolkningsbart språk, ledande till att ovannämnda egenskaper kan bestämmas från specifikationen.Operational support network according to claim 1 or 2, characterized in that the specification of the operational support information model is in the form of a definable representation of the operational support information model, which later defines - which states of interest from the operational support point of view the managed system can accept - operations , j - which operations can be directed at a managed system in a particular state, and finally - which state the managed system achieves when subjected to a particular operation, whereby a definable representation means that the above definitions can be expressed in a machine-interpretable language , leading to the above properties being determined from the specification. 4. Driftstödsnät enligt krav 3, kännetecknat av att det specificeras en unik uppsättning av tillåtna operationer i ett visst tillstånd hos nämnda hanterade system med hjälp av för- villkor och/eller slutvillkor, vilka utgör en logisk del av klassen av styrda objekt, eller en grupp av sådana klasser, 66 varvid ett förvillkor anger i vilket tillstånd det hanterade systemet måste vara för att en operation skall godkännas, och ett slutvillkor anger i vilket tillstånd det hanterade systemet skall vara efter en uppdateringstransaktion.Operating support network according to claim 3, characterized in that a unique set of permitted operations in a certain state of said managed system is specified by means of preconditions and / or end conditions, which form a logical part of the class of controlled objects, or a group of such classes, 66 wherein a condition precedes the condition in which the managed system must be in order for an operation to be approved, and a final condition indicates the condition of the managed system after an update transaction. 5. Driftstödsnät enligt krav 4, kännetecknat av att slutvill- kor definieras så att de uppfylls enligt endera av två strategi- er, nämligen: - driftstödsystemet uppdaterar det hanterade systemet på sådant sätt att slutvillkoren upprätthålls, i vilket fall en driftstödhanterare har ansvar för att villkoret uppfylls, varvid om driftstödhanteraren ignorerar detta ansvar det hanterade systemet förkastar uppdateringstransaktionen, eller - det hanterade systemet upprätthåller satta begränsningar genom att automatiskt genomföra nödvändiga sekundära uppdate- ringar för att tillfredsställa slutvillkoret.Operating support network according to claim 4, characterized in that end conditions are defined so that they are met according to either of two strategies, namely: - the operating support system updates the managed system in such a way that the final conditions are maintained, in which case an operating support manager is responsible for the condition is met, whereby if the operating support manager ignores this responsibility the managed system rejects the update transaction, or - the managed system maintains set limits by automatically performing the necessary secondary updates to satisfy the final condition. 6. Driftstödsnät enligt krav 5, kännetecknat av att bindning av slutvillkoren kan ske till metoder och skapa-operationer.Operating support network according to claim 5, characterized in that binding of the final conditions can take place to methods and creation operations. 7. Driftstödsnät enligt något av patentkraven 4-6, känneteck- nat av att slutvillkor specificeras i en driftstödsinformations- modell av ett hanterat system, varvid slutvillkoret anger en statisk konsistensbegränsning, som ej får överträdas i det hanterade systemet, varvid slutvillkoret är tillämpbart på en databas i det hanterade systemet och avser objektinstanser och deras attributvärden, som lagras i databasen.Operating support network according to one of Claims 4 to 6, characterized in that the end condition is specified in an operating support information model of a managed system, the end condition indicating a static consistency limitation which must not be violated in the managed system, the end condition being applicable to a database in the managed system and refers to object instances and their attribute values, which are stored in the database. 8. Driftstödsnät enligt något av patentkraven 4-7, känneteck- nat av att slutvillkor kan ange beroenden mellan attributvärden, kardinalitet hos attribut och databasrelationer, d.v.s. begränsningar med avseende på antalet värden hos ett attribut, begränsningar med avseende på antalet instanser av en objekt- typ.Operating support network according to one of Claims 4 to 7, characterized in that final conditions can indicate dependencies between attribute values, cardinality of attributes and database relations, i.e. constraints on the number of values of an attribute, constraints on the number of instances of an object type. 9. Driftstödsnät enligt något av patentkraven 4-8, känneteck- nat av att förvillkor anger en begränsning för tillståndet hos en databas i det hanterade systemet, vilken begränsning måste vara uppfylld innan en transaktion med en viss operation i databasen börjar.Operating support network according to one of Claims 4 to 8, characterized in that the preconditions state a restriction on the state of a database in the managed system, which restriction must be fulfilled before a transaction with a certain operation in the database begins. 10. Driftstödsnät enligt något av krav 5-9, kännetecknat av att vid användning av den första strategin utförs konsistenskontroller i trans- éš-TÜ 456 67 aktionen innan denna commitas, varvid endast om inget slutvill- kor överträds transaktionen genomförs, annars rullas den till- baka, den andra strategin genomförs automatiska korrigeringsåt- gärder i transaktionen innan den commitas, såsom exempelvis när ett visst attribut har uppdaterats.Operational support network according to one of Claims 5 to 9, characterized in that when using the first strategy, consistency checks are performed in the trans-éš-TÜ 456 67 action before it is committed, whereby only if no final conditions are violated is the transaction performed, otherwise - bake, the second strategy performs automatic correction actions in the transaction before it is committed, such as when a certain attribute has been updated. 11. Driftstödsnät enligt något av krav 1-10, kännetecknat av att för konstruktion av återanvändbara komponenter, vilka in- nehåller funktionalitet, som kan inkluderas i ett styrt objekt i ett hanterat system, kan en komponent med en viss funktionalitet konstrueras för att generera händelser, på vilka komponenter, som är okända för sistnämnda komponent, kan prenumerera.Operating support network according to one of Claims 1 to 10, characterized in that for the construction of reusable components, which contain functionality which can be included in a controlled object in a managed system, a component with a certain functionality can be constructed to generate events. , on which components, which are unknown for the latter component, can subscribe. 12. Driftstödsnät enligt krav 11, kännetecknat av att för konstruktion av komponenter, som innehåller attribut, genereras händelser vid förändring av attributvärden.Operating support network according to claim 11, characterized in that for the construction of components which contain attributes, events are generated when changing attribute values. 13. Driftstödsnät enligt något av föregående krav, för att implementera ett styrt objekt i ett delsystem av det hanterade systemet, varvid med delsystem avses varje del av ett hanterat system, som innehåller ett eller flera styrda objekt och data- basrelationer mellan styrda objekt, kännetecknat av att det styrda objektet implementeras i delsystemet, okoordinerat rela- tivt de andra delsystemen, på sådant sätt att det kan anslutas till och sända meddelanden till andra objekt i andra delsystem, och utan att känna typen av objekten i de andra delsystemen.Operating support network according to any one of the preceding claims, for implementing a controlled object in a subsystem of the managed system, wherein subsystem refers to any part of a managed system which contains one or more controlled objects and database relations between controlled objects, characterized of the controlled object being implemented in the subsystem, uncoordinated relative to the other subsystems, in such a way that it can be connected to and send messages to other objects in other subsystems, and without knowing the type of objects in the other subsystems. 14. Driftstödsnät enligt krav 13, kännetecknat av att ett första objekt konstrueras för att samverka med ett abstrakt objekt, som definierar ett gränssnitt bestående av oimplemente- rade metoder, vilka kan anropas av det första objektet, varvid vid senare konstruktion av ett för nämnda första objekt okänt andra objekt avsett att kunna samverka med det första objektet, det andra objektet ärver det abstrakta objektet och implemente- rar de ärvda metoderna, så att det första objektet vid samverkan med det andra objektet kommer att betrakta detta såsom varande av nämnda abstrakta typ.Operating support network according to claim 13, characterized in that a first object is constructed to cooperate with an abstract object, which defines an interface consisting of unimplemented methods, which can be called by the first object, wherein in later construction of a for said first object unknown second object intended to be able to interact with the first object, the second object inherits the abstract object and implements the inherited methods, so that the first object when interacting with the second object will regard this as being of said abstract type. 15. Driftstödsnät enligt krav 14, kännetecknat av att vid anrop av en metod definierad i gränssnittet hos det abstrakta objektet kommer anropet att delegeras till implementationen i det verkliga objektet med hjälp av sen bindning.Operating support network according to claim 14, characterized in that when calling a method defined in the interface of the abstract object, the call will be delegated to the implementation in the real object by means of late binding. 16. Driftstödsnät enligt krav 4 och 15, kännetecknat av att I 4 F' <5 O. f" Û 68 slutvillkor specificeras för en grupp av klasser där klasserna kan höra till olika delsystem.Operating support network according to claims 4 and 15, characterized in that I 4 F '<5 O. f "Û 68 final conditions are specified for a group of classes where the classes can belong to different subsystems. 17. Driftstödsnät enligt något av krav 14-16, kännetecknat av att omladdning av nämnda första objekt i det hanterade systemet vid laddning av nämnda andra objekt undviks med dynamisk län- kning mellan de respektive delsystemen.Operating support network according to any one of claims 14-16, characterized in that reloading of said first objects in the managed system when loading said second objects is avoided with dynamic linking between the respective subsystems. 18. Driftstödsnät enligt något av krav 14-17, kännetecknat av att nämnda första och andra objekt är belägna i varsitt första resp. andra delsystem.Operating support network according to any one of claims 14-17, characterized in that said first and second objects are located in respective first resp. other subsystems. 19. Driftstödsnät enligt krav 18, kännetecknat av att för att möjliggöra laddning i det hanterade systemet av nämnda andra delsystem utan omladdning av nämnda första delsystem används dynamisk länkning.Operating support network according to claim 18, characterized in that in order to enable loading in the managed system of said second subsystem without reloading of said first subsystem, dynamic linking is used. 20 Driftstödnät enligt något av krav 1-10, kännetecknat av att från modellrepresentationen kan den generella driftstöd- hanteraren fatta beslut med avseende på vilka operationer, som kan ske mot ett hanterat system, och kan avgöra vilka operatio- ner, som krävs för att uppnå ett önskat tillstånd hos detta.Operating support network according to one of Claims 1 to 10, characterized in that from the model representation the general operating support manager can make decisions with regard to which operations can take place against a managed system, and can determine which operations are required to achieve a desired condition of this. 21. Driftstödnät enligt något av krav 1,2,3 eller 20, känne- tecknat av att representationen av driftstödsinformationsmodel- len används för tolkning och förpackning av datastrukturer från resp. till hanterat system.Operational support network according to one of Claims 1, 2, 3 or 20, characterized in that the representation of the operational support information model is used for interpretation and packaging of data structures from resp. to managed system. 22. Driftstödnät enligt något av krav 1,2,3,20 eller 21, kännetecknat av att driftstödsinformationsmodellen och implemen- teringen av styrda objekt i systemet görs med samma specifika- tion i ett maskintolkningsbart språk, varvid specifikationerna av de styrda objekten i detta språk tillsammans bildar specifi- kationen för driftstödsinformationsmodellen.Operating support network according to one of Claims 1, 2, 3, 20 or 21, characterized in that the operating support information model and the implementation of controlled objects in the system are made with the same specification in a machine-interpretable language, the specifications of the controlled objects in this language together form the specification for the operational support information model. 23. Driftstödnät enligt krav 22, kännetecknat av att speci- fikationen av ett styrt objekt överförs till en kompilator, av vilken implementeringskod och ett godtyckligt mellanformat för representationen av det styrda objektets driftstödsinformations- modell genereras.Operating support network according to claim 22, characterized in that the specification of a controlled object is transmitted to a compiler, from which implementation code and an arbitrary intermediate format for the representation of the controlled support operating information model of the controlled object are generated. 24. Driftstödnät enligt krav 23, kännetecknat av att imple- mentationen förpackas tillsammans med mellanformatet till ett laddningspaket, som laddas i det hanterade systemet, och varvid under denna laddningsprocess mellanformatet används för att addera det det styrda objektets driftstödsinformationsmodell till systemets driftstödsinformationsmodell. n NB 456 69Operating support network according to claim 23, characterized in that the implementation is packaged together with the intermediate format of a charging packet, which is loaded in the managed system, and during this charging process the intermediate format is used to add the controlled support information model of the controlled object to the operating support information model. n NB 456 69 25. Driftstödnät enligt krav 24, kännetecknat av att i det hanterade systemet implementeras representationen av driftst- ödsinformationsmodellen som instanser av en speciell klass av styrda objekt, och att för varje klass av styrda objekt skapas en instans av denna speciella klass.Operational support network according to claim 24, characterized in that in the managed system the representation of the operational support information model is implemented as instances of a special class of controlled objects, and that for each class of controlled objects an instance of this special class is created. 26. Driftstödnät enligt krav 25, kännetecknat av att för installering av objekt av nämnda speciella klass i det hanterade systemet exekveras i implementationskoden av styrda objekt en installationsmetod, som medför att en instans av nämnda speciel- la klass installeras.Operating support network according to claim 25, characterized in that for the installation of objects of said special class in the managed system, an installation method is executed in the implementation code of controlled objects, which entails that an instance of said special class is installed. 27. Driftstödnät enligt något av krav 20-26, kännetecknat av att den generella driftstödhanteraren har ett användargräns- snitt, vilket genereras under drift baserat på representationen av infomationsmodellen, och i vilket alla styrda objekt hos det hanterade systemet kan inspekteras och modifieras.Operating support network according to any one of claims 20-26, characterized in that the general operating support manager has a user interface, which is generated during operation based on the representation of the information model, and in which all controlled objects of the managed system can be inspected and modified. 28. Driftstödnät enligt krav 27, kännetecknat av att den generella driftstödshanteraren under drift hanterar förändringar i det hanterade systemets driftstödsinformationsmodell genom att transformera en representation av det hanterade systemets drift- stödsinformationsmodell till en, för den generella drifstödshan- teraren, intern representation.Operating support network according to claim 27, characterized in that the general operating support manager during operation handles changes in the managed system's operating support information model by transforming a representation of the managed system's operating support information model into an internal representation for the general operating support manager. 29. Driftstödnät enligt något av krav 26-28, kännetecknat av att den generella hanteraren känner till nämnda speciella ob- jektklass' gränssnitt, som utgör representationen av driftstöds- informationsmodellen.Operating support network according to any one of claims 26-28, characterized in that the general manager is aware of said special object class' interface, which constitutes the representation of the operating support information model. 30. Driftstödnät enligt något av krav 26-29, kännetecknat av att det för varje klass av styrda objekt finns en resursagent, i vilken den för klassen av styrda objekt unika termineringen av drifthanteringssystemets protokol utföres, och vilken resuragent kan bestå av tre delar, nämligen en underagent till ett hjälpgränssnitt för styrda objekt, vilket är ett generellt gränssnitt, som tillhandahålls av alla resursagenter, och vars operationerna är skapa, radera, skriv, läs och metod, och i vilket operationer alltid är riktade mot en viss instans av en viss klass av styrda objekt, en dataobjektlogik, och/eller en komplementär logik, varvid resursagenten vidare tillhandahåller hjälpgränssnittet för styrda objekt som yttre gränssnitt, har två inre gränssnitt, :-iâ ¿='Ü o. 70 nämligen ett gränssnitt för dataobjekt, och ett gränssnitt för den komplementära logiken. 'Operating support network according to any one of claims 26-29, characterized in that for each class of controlled objects there is a resource agent, in which the termination of the operation management system protocol unique to the class of controlled objects is performed, and which resource agent can consist of three parts, namely a sub-agent of an auxiliary interface for controlled objects, which is a general interface, provided by all resource agents, and whose operations are create, delete, write, read and method, and in which operations are always directed to a certain instance of a certain class of controlled objects, a data object logic, and / or a complementary logic, wherein the resource agent further provides the auxiliary interface for controlled objects as external interfaces, has two internal interfaces,: -iâ ¿= 'Ü o. 70 namely a data object interface, and an interface for the complementary logic. ' 31. Driftstödnät enligt krav 30, kännetecknat av att resurs- agentens definition innefattar specifikationen för styrda objekt, vilken erhållits genom definiering i ett maskintolk- ningsbart språk av egenskaperna hos de styrda objekten, och definierar vilka egenskaper hos resursagenten, som utgör det styrda objektet.Operating support network according to claim 30, characterized in that the resource agent's definition comprises the specification for controlled objects, which is obtained by defining in a machine-interpretable language the properties of the controlled objects, and defining which properties of the resource agent constitute the controlled object. 32. Driftstödnät enligt krav 30 eller 31, kännetecknat av att implementationen av hjälpgränssnittet genereras utifrån specifi- kationen av det styrda objektet.Operating support network according to claim 30 or 31, characterized in that the implementation of the auxiliary interface is generated on the basis of the specification of the controlled object. 33. Driftstödsnät enligt krav 1,2,3 eller 20, kännetecknat av att den generella driftstödhanteraren utifrån en representation av driftstödsinformationsmodellen kan interagera med ett hante- rat system på sådant sätt att begrepp i driftstödsinformations- modellen transformeras till representationer och strukturer lämpliga för användning av en yttre användare, såsom ett fön- sterhanteringssystem, en databashanterare etc.Operating support network according to claims 1,2,3 or 20, characterized in that the general operating support manager can interact with a managed system based on a representation of the operating support information model in such a way that concepts in the operating support information model are transformed into representations and structures suitable for use. an external user, such as a window management system, a database manager, etc. 34. Driftstödsnät enligt krav 33, kännetecknat av att den generella driftstödhanteraren mjukvarumässigt skapar en intern representation av det hanterade systemets driftstödinformations- modell genom att tolka denna och presentera den för en yttre användare som på så sätt kan interagera med det hanterade syste- met.Operating support network according to claim 33, characterized in that the general operating support manager software-wise creates an internal representation of the managed support operating information model of the managed system by interpreting it and presenting it to an external user who can thus interact with the managed system. 35. Driftstödsnät enligt krav 34, kännetecknat av att den generella driftstödhanteraren utnyttjar den interna representa- tionen av det hanterade systemets driftstödinformationsmodell för att vidmakthålla modellens konsistens genom att analysera en yttre användares interaktionsmönster och vidta eller föreslå operationer mot det hanterade systemet.Operating support network according to claim 34, characterized in that the general operating support manager uses the internal representation of the managed system operating support information model to maintain the consistency of the model by analyzing an external user's interaction pattern and performing or proposing operations against the managed system. 36. Driftstödsnät enligt krav 34 eller 35, kännetecknat av att den generella driftstödhanteraren genom att tolka den in- terna representationen av det hanterade systemets driftstödsin- formationsmodell kan leda/föreslå operationer, i enlighet med konsistensregler, för en interaktiv användare av den generella driftstödhanteraren.Operating support network according to claim 34 or 35, characterized in that the general operating support manager by interpreting the internal representation of the managed system operating support information model can lead / propose operations, in accordance with consistency rules, for an interactive user of the general operating support manager. 37. Driftstödsnät enligt krav 1,2,3 eller 20, kännetecknat av att den generella driftstödhanteraren innehåller funktioner som möjliggör att en yttre användare kan interagera med det hantera- 71 de systemet genom att manipulera representationer av det hante- rade systemets driftstödsinformationsmodell.Operating support network according to claim 1, 2, 3 or 20, characterized in that the general operating support manager contains functions which enable an external user to interact with the managed system 71 by manipulating representations of the operating support information model of the managed system. 38. Driftstödsnät enligt krav 37, kännetecknat av att den generella driftstödhanteraren innehåller en yttre representa- tionsenhet som omvandlar för den generella driftstödhanteraren interna representationer till representationer anpassade till en i förhållande till den generella driftstödhanteraren extern användare av t.ex. ett fönsterhanteringssystem, databashanterare etc.Operating support network according to claim 37, characterized in that the general operating support manager contains an external representation unit which converts internal representations for the general operating support manager into representations adapted to an external user of e.g. a window management system, database manager, etc. 39. Driftstödsnät enligt krav 37 eller 38, kännetecknat av att den generella driftstödhanteraren innehåller en modelltolk som kan tolka den generiska representationen av det hanterade systemets driftstödsinformationsmodell.Operating support network according to claim 37 or 38, characterized in that the general operating support manager contains a model interpreter which can interpret the generic representation of the managed support information model of the managed system. 40. Driftstödsnät enligt något av krav 37-39, kännetecknat av att den generella driftstödhanteraren innehåller en funktion som genom att tolka en intern representation av driftstödinforma- tionsmodellen kan skapa en eller flera syntaktiskt och seman- tiskt riktiga operationer som kan riktas mot det hanterade systemet.Operating support network according to one of Claims 37 to 39, characterized in that the general operating support manager contains a function which, by interpreting an internal representation of the operating support information model, can create one or more syntactically and semantically correct operations which can be directed at the managed system. . 41. Driftstödsnät enligt något av krav 37-40, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt mot driftstödsnätet som används för att ta emot händelser i det hanterade systemet och rikta operationer mot detsamma, och för överföring och åtkomst av den i det hanterade systemet lagrade representationen av driftstödsinformationsmodellen.Operating support network according to one of Claims 37 to 40, characterized in that the general operating support manager contains access interfaces to the operating support network which are used for receiving events in the managed system and directing operations towards the same, and for transmitting and accessing it in the managed operating system. the system stored the representation of the operational support information model. 42. Driftstödsnät enligt något av krav 37-41, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt som möjliggör att samma generiska representationer av hanterat systems driftstödsinformationsmodell kan skickas över olika typer av kommunikationsnät.Operating support network according to one of Claims 37 to 41, characterized in that the general operating support manager contains access interfaces which enable the same generic representations of the managed support operating information model of a managed system to be transmitted over different types of communication networks. 43. Driftstödsnät enligt något av krav 37-42, kännetecknat av att den generella driftstödhanteraren implementeras enligt en modell, som innefattar funktionalitet för att kunna utnyttja representationen av det hanterade systemets driftstödinforma- tionsmodell och göra transformationer till representationer lämpliga för en yttre användare utan att någon extra/ny informa- tion tillförs representationen av driftstödsinformationsmodellen utöver det som är specificerat och lagrat i det hanterade syste- met. \,~"| .f Û CI) .J,2:~. CH 72Operating support network according to any one of claims 37-42, characterized in that the general operating support manager is implemented according to a model, which includes functionality to be able to use the representation of the managed system operating support information model and make transformations into representations suitable for an external user. extra / new information is added to the representation of the operating support information model in addition to what is specified and stored in the managed system. \, ~ "| .f Û CI) .J, 2: ~. CH 72 44. Driftstödnät med minst ett driftstödsystem och minst ett hanterat system, för telekommunikations- eller öppna system, varvid nämnda hanterade system innehåller fysiska och/eller logiska resurser, som av driftstödsystemet betraktas och hante- ras som styrda objekt i form av databilder av resurserna, varvid driftstödsystemet för sina mot det hanterade systemet riktade operationer utnyttjar en driftstödsinformationsmodell av det hanterade systemet, vilken innehåller en till driftstödsystemets arbetssätt anpassad beskrivning av alla styrda objekt, känne- tecknat av att i det hanterade systemet implementeras en repre- sentation av driftstödsinformationsmodellen som instanser av en speciell klass av styrda objekt.44. Operational support networks with at least one operating support system and at least one managed system, for telecommunication or open systems, said managed systems containing physical and / or logical resources, which are considered by the operating support system and managed as controlled objects in the form of data images of the resources, the operating support system for its operations directed towards the managed system uses an operating support information model of the managed system, which contains a description of all controlled objects adapted to the operating support system's operation, characterized in that the management system implements a representation of the operating support information model. a special class of controlled objects. 45. Driftstödnät enligt krav 44, kännetecknat av att drift- stödsinformationsmodellens specifikation är i form av en be- stämbar representation av driftstödsinformationsmodellen, vilken senare definierar - vilka tillstånd av intresse från driftstödsynpunkt det hanterade systemet kan anta, - vilka operationer som kan accepteras av det hanterade systemet, - vilka operationer som kan riktas mot ett hanterat system i ett visst tillstånd, samt slutligen - vilket tillstånd det hanterade systemet uppnår när det utsätts för en viss operation, varvid med en bestämbar representation avses att ovanstående definitioner skall kunna uttryckas i ett maskintolkningsbart språk, ledande till att ovannämnda egenskaper kan bestämmas från specifikationen.Operating support network according to claim 44, characterized in that the specification of the operating support information model is in the form of a determinable representation of the operating support information model, which later defines - which states of interest from the operating support point of view the managed system can assume, - which operations can be accepted by the managed system, - which operations can be directed to a managed system in a particular state, and finally - what state the managed system achieves when subjected to a particular operation, whereby a definable representation means that the above definitions can be expressed in a machine interpretable language, leading to the above properties being determined from the specification. 46. Driftstödnät enligt krav 45, kännetecknat av att det specificeras en unik uppsättning av tillåtna operationer i ett visst tillstånd hos nämnda hanterade system med hjälp av för- villkor och/eller slutvillkor, vilka utgör en logisk del av klassen av styrda objekt, eller en grupp av sådana klasser, varvid ett förvillkor anger i vilket tillstånd det hanterade systemet måste vara för att en operation skall godkännas, och ett slutvillkor anger i vilket tillstånd det hanterade systemet skall vara efter en uppdateringstransaktion.Operating support network according to claim 45, characterized in that a unique set of permitted operations is specified in a certain state of said managed system by means of preconditions and / or end conditions, which form a logical part of the class of controlled objects, or a group of such classes, a prerequisite indicating the state in which the managed system must be in order for an operation to be approved, and a final condition indicating the state in which the managed system must be after an update transaction. 47. Driftstödnät enligt krav 46, kännetecknat av att slut- villkor definieras så att de uppfylls enligt endera av två mm ~L1 C 3 -Eh (f: Qx 73 strategier, nämligen: - driftstödsystemet uppdaterar det hanterade systemet på sådant sätt att slutvillkoren upprätthålls, i vilket fall en driftstödhanterare har ansvar för att villkoret uppfylls, varvid om driftstödhanteraren ignorerar detta ansvar det hanterade systemet förkastar en uppdateringstransaktion, eller - det hanterade systemet upprätthåller satta begränsningar genom att automatiskt genomföra nödvändiga sekundära uppdate- ringar för att tillfredsställa slutvillkoret.Operating support network according to claim 46, characterized in that end conditions are defined so that they are met according to either of two mm ~ L1 C 3 -Eh (f: Qx 73 strategies, namely: - the operating support system updates the managed system in such a way that the final conditions are maintained , in which case an operational support manager is responsible for compliance with the condition, whereby if the operational support manager ignores this responsibility the managed system rejects an update transaction, or - the managed system maintains set limits by automatically performing necessary secondary updates to satisfy the final condition. 48. Driftstödnät enligt krav 46 eller 47, kännetecknat av att bindning av slutvillkoren kan ske till metoder och skapa-operat- ioner.Operating support network according to claim 46 or 47, characterized in that binding of the final conditions can take place to methods and create operations. 49. Driftstödnät enligt något av patentkraven 44-48, känne- tecknat av att slutvillkor specificeras i en driftstödsinforma- tionsmodell av ett hanterat system, varvid slutvillkoret anger en statisk konsistensbegränsning, som ej får överträdas i det hanterade systemet, varvid slutvillkoret är tillämpbart på en databas i det hanterade systemet och avser objektinstanser och deras attributvärden, som lagras i databasen.Operating support network according to one of Claims 44 to 48, characterized in that the end condition is specified in an operating support information model of a managed system, the end condition indicating a static consistency limitation which may not be violated in the managed system, the end condition being applicable to a database in the managed system and refers to object instances and their attribute values, which are stored in the database. 50. Driftstödnät enligt något av patentkraven 44-49, känne- tecknat av att slutvillkor kan ange beroenden mellan attributvärden, kardinalitet hos attribut och databasrelationer, d.v.s. begränsningar med avseende på antalet värden hos ett attribut, begränsningar med avseende på antalet instanser av en objekt- typ.Operating support network according to any one of claims 44-49, characterized in that final conditions can indicate dependencies between attribute values, cardinality of attributes and database relations, i.e. constraints on the number of values of an attribute, constraints on the number of instances of an object type. 51. Driftstödnät enligt något av patentkraven 44-50, känne- tecknat av att förvillkor anger en begränsning för tillståndet hos en databas i det hanterade systemet, vilken begränsning måste vara uppfylld innan en transaktion med en viss operation i databasen börjar.Operating support network according to one of Claims 44 to 50, characterized in that the conditions state a restriction on the state of a database in the managed system, which restriction must be fulfilled before a transaction with a certain operation in the database begins. 52. Driftstödnät enligt något av krav 44-51, kännetecknat av att vid användning av den första strategin utförs konsistenskontroller i trans- aktionen innan denna commitas, varvid endast om inget slutvill- kor överträds transaktionen genomförs, annars rullas den till- baka, den andra strategin genomförs automatiska korrigeringsåt- gärder i transaktionen innan den commitas, såsom exempelvis när LL f WH /U 'T o.. 74 ett visst attribut har uppdaterats.Operating aid network according to any one of claims 44-51, characterized in that when using the first strategy, consistency checks are performed in the transaction before it is committed, whereby only if no final conditions are violated, the transaction is performed, otherwise it is rolled back, the second the strategy performs automatic correction measures in the transaction before it is committed, such as when LL f WH / U 'T o .. 74 a certain attribute has been updated. 53. Driftstödnät enligt något av krav 44-52, kännetecknat av att för konstruktion av återanvändbara komponenter, vilka in- nehåller funktionalitet, som kan inkluderas i ett styrt objekt i ett hanterat system, kan en komponent med en viss funktionalitet konstrueras för att generera händelser, på vilka komponenter, som är okända för sistnämnda komponent, kan prenumerera.Operating support network according to any one of claims 44-52, characterized in that for the construction of reusable components, which contain functionality that can be included in a controlled object in a managed system, a component with a certain functionality can be constructed to generate events. , on which components, which are unknown for the latter component, can subscribe. 54. Driftstödnät enligt krav 53, kännetecknat av att för konstruktion av komponenter, som innehåller attribut, genereras händelser vid förändring av attributvärden.Operating support network according to claim 53, characterized in that for the design of components containing attributes, events are generated when changing attribute values. 55. Driftstödnät enligt något av 44-54, kännetecknat av att representationen av driftstödsinformationsmodellen används för tolkning och förpackning av datastrukturer från resp. till hanterat system.55. Operational support network according to any one of 44-54, characterized in that the representation of the operational support information model is used for interpretation and packaging of data structures from resp. to managed system. 56. Driftstödnät enligt något av krav 44-55, kännetecknat av att driftstödsinformationsmodellen och implementeringen av styrda objekt i systemet görs med samma specifikation i ett maskintolkningsbart språk, varvid specifikationerna av de styrda objekten i detta språk tillsammans bildar specifikationen för driftstödsinformationsmodellen.Operating support network according to any one of claims 44-55, characterized in that the operating support information model and the implementation of controlled objects in the system are made with the same specification in a machine interpretable language, the specifications of the controlled objects in this language together forming the specification for the operational support information model. 57. Driftstödnät enligt krav 56, kännetecknat av att speci- fikationen av ett styrt objekt överförs till en kompilator, av vilken implementeringskod och ett godtyckligt mellanformat för representationen av det styrda objektets driftstödsinformations- modell genereras.Operating support network according to claim 56, characterized in that the specification of a controlled object is transmitted to a compiler, from which implementation code and an arbitrary intermediate format for the representation of the controlled support information model of the controlled object are generated. 58. Driftstödnät enligt krav 57, kännetecknat av att imple- mentationen förpackas tillsammans med mellanformatet till ett laddningspaket, som laddas i det hanterade systemet, och varvid under denna laddningsprocess mellanformatet används för att addera det det styrda objektets driftstödsinformationsmodell till systemets driftstödsinformationsmodell.Operating support network according to claim 57, characterized in that the implementation is packaged together with the intermediate format of a charging packet, which is loaded in the managed system, and during this charging process the intermediate format is used to add the controlled support information model of the controlled object to the operating support information model. 59. Driftstödnät enligt krav 58, kännetecknat av att för installering av objekt av nämnda speciella klass i det hanterade systemet exekveras i implementationskoden av styrda objekt en installationsmetod, som medför att en instans av nämnda speciel- la klass installeras.Operating support network according to claim 58, characterized in that for installation of objects of said special class in the managed system, an installation method is executed in the implementation code of controlled objects, which entails that an instance of said special class is installed. 60. Driftstödsnät enligt krav 44 eller 45, kännetecknat av att den generella driftstödhanteraren utifrån en representation av driftstödsinformationsmodellen kan interagera med ett hante- N *JJ CD .Fas LH C}\ 75 rat system på sådant sätt att begrepp i driftstödsinformations- modellen transformeras till representationer och strukturer lämpliga för användning av en yttre användare, såsom ett fön- sterhanteringssystem, en databashanterare etc.Operating support network according to claim 44 or 45, characterized in that the general operating support manager can, based on a representation of the operating support information model, interact with a managed N * JJ CD .Fas LH C} \ 75 system in such a way that concepts in the operating support information model are transformed into representations and structures suitable for use by an external user, such as a window management system, a database manager, etc. 61. Driftstödsnät enligt krav 60, kännetecknat av att den generella driftstödhanteraren mjukvarumässigt skapar en intern representation av det hanterade systemets driftstödinformations- modell genom att tolka denna och presentera den för en yttre användare som på så sätt kan interagera med det hanterade syste- met.Operating support network according to claim 60, characterized in that the general operating support manager software-wise creates an internal representation of the managed support operating information model of the managed system by interpreting it and presenting it to an external user who can thus interact with the managed system. 62. Driftstödsnät enligt krav 61, kännetecknat av att den generella driftstödhanteraren utnyttjar den interna representa- tionen av det hanterade systemets driftstödinformationsmodel1 för att vidmakthålla modellens konsistens genom att analysera en yttre användares interaktionsmönster och vidta eller föreslå operationer mot det hanterade systemet.Operating support network according to claim 61, characterized in that the general operating support manager uses the internal representation of the managed system operating support information model1 to maintain the consistency of the model by analyzing an external user's interaction pattern and performing or proposing operations against the managed system. 63. Driftstödsnät enligt krav 61 eller 62, kännetecknat av att den generella driftstödhanteraren genom att tolka den in- terna representationen av det hanterade systemets driftstödsin- formationsmodell kan leda/föreslå operationer, i enlighet med konsistensregler, för en interaktiv användare av den generella driftstödhanteraren.Operating support network according to claim 61 or 62, characterized in that the general operating support manager by interpreting the internal representation of the managed system operating support information model can lead / propose operations, in accordance with consistency rules, for an interactive user of the general operating support manager. 64. Driftstödsnät enligt krav 44 eller 45, kännetecknat av att den generella driftstödhanteraren innehåller funktioner som möjliggör att en yttre användare kan interagera med det hantera- de systemet genom att manipulera representationer av det hante- rade systemets driftstödsinformationsmodel1.Operating support network according to claim 44 or 45, characterized in that the general operating support manager contains functions enabling an external user to interact with the managed system by manipulating representations of the operating support information model of the managed system1. 65. Driftstödsnät enligt krav 64, kännetecknat av att den generella driftstödhanteraren innehåller en yttre representa- tionsenhet som omvandlar för den generella driftstödhanteraren interna representationer till representationer anpassade till en i förhållande till den generella driftstödhanteraren extern användare av t.ex. ett fönsterhanteringssystem, databashanterare etc.Operating support network according to claim 64, characterized in that the general operating support manager contains an external representation unit which converts internal representations for the general operating support manager into representations adapted to an external user of e.g. a window management system, database manager, etc. 66. Driftstödsnät enligt krav 64 eller 65, kännetecknat av att den generella driftstödhanteraren innehåller en modelltolk som kan tolka den generiska representationen av det hanterade systemets driftstödsinformationsmodel1.Operating support network according to claim 64 or 65, characterized in that the general operating support manager contains a model interpreter which can interpret the generic representation of the managed support information model 1 of the managed system. 67. Driftstödsnät enligt något av krav 64-66, kännetecknat av f 1 % -:1 U $\ 56 76 att den generella driftstödhanteraren innehåller en funktion som genom att tolka en intern representation av driftstödinforma- tionsmodellen kan skapa en eller flera syntaktiskt och seman- tiskt riktiga operationer som kan riktas mot det hanterade systemet.Operating support network according to any one of claims 64-66, characterized by f 1% -: 1 U $ \ 56 76 that the general operating support manager contains a function which by interpreting an internal representation of the operating support information model can create one or more syntactic and seman technically sound operations that can be directed at the managed system. 68. Driftstödsnät enligt något av krav 64-67, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt mot driftstödsnätet som används för att ta emot händelser i det hanterade systemet och rikta operationer mot detsamma, och för överföring och åtkomst av den i det hanterade systemet lagrade representationen av driftstödsinformationsmodellen.Operating support network according to one of Claims 64 to 67, characterized in that the general operating support manager contains access interfaces to the operating support network which are used for receiving events in the managed system and directing operations towards the same, and for transmitting and accessing it in the managed operating system. the system stored the representation of the operational support information model. 69. Driftstödsnät enligt något av krav 64-68, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt som möjliggör att samma generiska representationer av hanterat systems driftstödsinformationsmodell kan skickas över olika typer av kommunikationsnät.Operating support network according to one of Claims 64 to 68, characterized in that the general operating support manager contains access interfaces which enable the same generic representations of the operating support information model of the managed system to be transmitted over different types of communication networks. 70. Driftstödsnät enligt något av krav 64-69, kännetecknat av att den generella driftstödhanteraren implementeras enligt en modell, som innefattar funktionalitet för att kunna utnyttja representationen av det hanterade systemets driftstödinforma- tionsmodell och göra transformationer till representationer lämpliga för en yttre användare utan att någon extra/ny informa- tion tillförs representationen av driftstödsinformationsmodellen utöver det som är specificerat och lagrat i det hanterade syste- met.Operating support network according to any one of claims 64-69, characterized in that the general operating support manager is implemented according to a model, which includes functionality to be able to use the representation of the managed system operating support information model and make transformations into representations suitable for an external user without any extra / new information is added to the representation of the operating support information model in addition to what is specified and stored in the managed system. 71. Driftstödsnät med minst ett driftstödsystem och minst ett hanterat system, för telekom- eller öppna system, varvid nämnda hanterade system innehåller fysiska och/eller logiska resurser, som av driftstödsystemet betraktas och hanteras som styrda objekt i form av databilder av resurserna, och varvid drift- stödsystemet för sina mot det hanterade systemet riktade opera- tioner utnyttjar en driftstödsinformationsmodell av det hantera- de systemet, vilken innehåller en till driftstödsystemets ar- betssätt anpassad beskrivning av alla styrda objekt, känneteck- nat av att driftstödsinformationsmodellens specifikation är i form av en bestämbar representation av driftstödsinformationsmodellen, vilken senare definierar - vilka tillstånd av intresse från driftstödsynpunkt det \___~| CD 45-*- LT! O\ 77 hanterade systemet kan anta, - vilka operationer som kan accepteras av det hanterade systemet, - vilka operationer som kan riktas mot ett hanterat system i ett visst tillstånd, samt slutligen - vilket tillstånd det hanterade systemet uppnår när det utsätts för en viss operation, varvid med en bestämbar representation avses att ovanstående definitioner skall kunna uttryckas i ett maskintolkningsbart språk, ledande till att ovannämnda egenskaper kan bestämmas från specifikationen, samt att, för att definiera tillståndet hos ett visst hanterat system sker definition av: - vilka instanser av hanterade objekt, som kan existera och - vilka attribut de har och - vilka värden dessa attribut kan ha.71. Operational support networks with at least one operational support system and at least one managed system, for telecom or open systems, said managed system containing physical and / or logical resources, which are considered by the operating support system and managed as controlled objects in the form of data images of the resources, and the operating support system for its operations directed towards the managed system uses an operating support information model of the managed system, which contains a description of all controlled objects adapted to the operating support system's operation, characterized in that the operating support information model's specification is in the form of a determinable representation of the operating aid information model, which later defines - which states of interest from the operating aid point of view it \ ___ ~ | CD 45 - * - LT! The managed system can assume, - which operations can be accepted by the managed system, - which operations can be directed at a managed system in a certain state, and finally - what state the managed system achieves when it is subjected to a certain operation , whereby a definable representation means that the above definitions can be expressed in a machine-interpretable language, leading to the above-mentioned properties being determined from the specification, and that, in order to define the state of a particular managed system, a definition is made of: , which can exist and - what attributes they have and - what values these attributes can have. 72. Driftstödnät enligt krav 71, kännetecknat av att det specificeras en unik uppsättning av tillåtna operationer i ett visst tillstånd hos nämnda hanterade system med hjälp av för- villkor och/eller slutvillkor, vilka utgör en logisk del av klassen av styrda objekt, eller en grupp av sådana klasser, varvid ett förvillkor anger i vilket tillstånd det hanterade systemet måste vara för att en operation skall godkännas, och ett slutvillkor anger i vilket tillstånd det hanterade systemet skall vara efter en uppdateringstransaktion.Operating support network according to claim 71, characterized in that a unique set of permitted operations is specified in a certain state of said managed system by means of preconditions and / or end conditions, which form a logical part of the class of controlled objects, or a group of such classes, a prerequisite indicating the state in which the managed system must be in order for an operation to be approved, and a final condition indicating the state in which the managed system must be after an update transaction. 73. Driftstödnät enligt krav 72, kännetecknat av att slut- villkor definieras så att de uppfylls enligt endera av två strategier, nämligen: - driftstödsystemet uppdaterar det hanterade systemet på sådant sätt att slutvillkoren upprätthålls, i vilket fall en driftstödhanterare har ansvar för att villkoret uppfylls, varvid om driftstödhanteraren ignorerar detta ansvar det hanterade systemet förkastar en uppdateringstransaktion, eller - det hanterade systemet upprätthåller satta begränsningar genom att automatiskt genomföra nödvändiga sekundära uppdate- ringar för att tillfredsställa slutvillkoret.Operating aid network according to claim 72, characterized in that final conditions are defined so that they are met according to either of two strategies, namely: - the operating support system updates the managed system in such a way that the final conditions are maintained, in which case an operating support manager is responsible for compliance; , whereby if the operational support manager ignores this responsibility the managed system rejects an update transaction, or - the managed system maintains set limits by automatically performing the necessary secondary updates to satisfy the final condition. 74. Driftstödnät enligt krav 72 eller 73, kännetecknat av att bindning av slutvillkoren kan ske till metoder och skapa-opera- tioner. sa à. '7 l 4 % (Il n f U Ü 78Operating support network according to Claim 72 or 73, characterized in that the final conditions can be bound to methods and creation operations. sa à. '7 l 4% (Il n f U Ü 78 75. Driftstödnät enligt något av patentkraven 72-74, känne- tecknat av att slutvillkor specificeras i en driftstödsinforma- tionsmodell av ett hanterat system, varvid slutvillkoret anger en statisk konsistensbegränsning, som ej får överträdas i det hanterade systemet, varvid slutvillkoret är tillämpbart på en databas i det hanterade systemet och avser objektinstanser och deras attributvärden, som lagras i databasen.Operating support network according to one of Claims 72 to 74, characterized in that the end condition is specified in an operating support information model of a managed system, the end condition indicating a static consistency limitation which may not be violated in the managed system, the end condition being applicable to a database in the managed system and refers to object instances and their attribute values, which are stored in the database. 76. Driftstödnät enligt något av patentkraven 72-75, känne- tecknat av att slutvillkor kan ange beroenden mellan attributvärden, kardinalitet hos attribut och databasrelationer, d.v.s. begränsningar med avseende på antalet värden hos ett attribut, begränsningar med avseende på antalet instanser av en objekt- typ.Operating support network according to one of Claims 72 to 75, characterized in that final conditions can indicate dependencies between attribute values, cardinality of attributes and database relations, i.e. constraints on the number of values of an attribute, constraints on the number of instances of an object type. 77. Driftstödnät enligt något av patentkraven 72-76, känne- tecknat av att förvillkor anger en begränsning för tillståndet hos en databas i det hanterade systemet, vilken begränsning måste vara uppfylld innan en transaktion med en viss operation i databasen börjar.Operating support network according to one of Claims 72 to 76, characterized in that the preconditions state a limit on the state of a database in the managed system, which limit must be met before a transaction with a certain operation in the database begins. 78. Driftstödnät enligt något av krav 73-77, kännetecknat av att vid användning av den första strategin utförs konsistenskontroller i trans- aktionen innan denna commitas, varvid endast om inget slutvill- kor överträds transaktionen genomförs, annars rullas den till- baka, den andra strategin genomförs automatiska korrigeringsåt- gärder i transaktionen innan den commitas, såsom exempelvis när ett visst attribut har uppdaterats.Operating aid network according to one of Claims 73 to 77, characterized in that when using the first strategy, consistency checks are performed in the transaction before it is committed, whereby only if no final conditions are violated, the transaction is carried out, otherwise it is rolled back, the second The strategy implements automatic correction measures in the transaction before it is committed, such as when a certain attribute has been updated. 79. Driftstödnät enligt något av krav 71-78, kännetecknat av att för konstruktion av återanvändbara komponenter, vilka in- nehåller funktionalitet, som kan inkluderas i ett styrt objekt i ett hanterat system, kan en komponent med en viss funktionalitet konstrueras för att generera händelser, på vilka komponenter, som är okända för sistnämnda komponent, kan prenumerera.Operating support network according to any one of claims 71-78, characterized in that for the construction of reusable components, which contain functionality that can be included in a controlled object in a managed system, a component with a certain functionality can be constructed to generate events. , on which components, which are unknown for the latter component, can subscribe. 80. Driftstödnät enligt krav 79, kännetecknat av att för konstruktion av komponenter, som innehåller attribut, genereras händelser vid förändring av attributvärden.Operating support network according to claim 79, characterized in that for the construction of components containing attributes, events are generated when changing attribute values. 81. Driftstödnät enligt något av krav 71-80, i vilket ett styrt objekt skall implementeras i ett delsystem av ett hanterat ~\..,'] »Eb 01 ON 0 79 system, varvid med delsystem avses varje del av ett hanterat system, som innehåller ett eller flera styrda objekt och data- basrelationer mellan styrda objekt, kännetecknat av att det styrda objektet implementeras i delsystemet, okoordinerat rela- tivt de andra delsystemen, på sådant sätt att det kan anslutas till och sända meddelanden till andra objekt i andra delsystem, och utan att känna typen av objekten i de andra delsystemen.An operating support network according to any one of claims 71-80, in which a controlled object is to be implemented in a subsystem of a managed system, wherein subsystem refers to each part of a managed system, containing one or more controlled objects and database relations between controlled objects, characterized in that the controlled object is implemented in the subsystem, uncoordinated relative to the other subsystems, in such a way that it can be connected to and send messages to other objects in other subsystems , and without knowing the type of objects in the other subsystems. 82. Driftstödnät enligt krav 81, kännetecknat av att ett första objekt konstrueras för att samverka med ett abstrakt objekt, som definierar ett gränssnitt bestående av oimplemente- rade metoder, vilka kan anropas av det första objektet, varvid vid senare konstruktion av ett för nämnda första objekt okänt andra objekt avsett att kunna samverka med det första objektet, det andra objektet ärver det abstrakta objektet och implemente- rar de ärvda metoderna, så att det första objektet vid samverkan med det andra objektet kommer att betrakta detta såsom varande av nämnda abstrakta typ.Operating support network according to claim 81, characterized in that a first object is constructed to cooperate with an abstract object, which defines an interface consisting of unimplemented methods, which can be called by the first object, wherein in later construction of a for said first object unknown second object intended to be able to interact with the first object, the second object inherits the abstract object and implements the inherited methods, so that the first object when interacting with the second object will regard this as being of said abstract type. 83. Driftstödnät enligt krav 82, kännetecknat av att vid anrop av en metod definierad i gränssnittet hos det abstrakta objektet kommer anropet att delegeras till implementationen i det verkliga objektet med hjälp av sen bindning.Operating support network according to claim 82, characterized in that when calling a method defined in the interface of the abstract object, the call will be delegated to the implementation in the real object by means of late binding. 84. Driftstödnät enligt krav 71 och 83, kännetecknat av att slutvillkor specificeras för en grupp av klasser där klasserna kan höra till olika delsystem.Operating aid network according to claims 71 and 83, characterized in that final conditions are specified for a group of classes where the classes can belong to different subsystems. 85. Driftstödnät enligt krav 82 eller 83, kännetecknat av att omladdning av originalobjektet i det hanterade systemet vid laddning av nämnda andra objekt undviks med dynamisk länkning mellan de respektive delsystemen.Operating support network according to claim 82 or 83, characterized in that reloading of the original object in the managed system when loading said second object is avoided with dynamic linking between the respective subsystems. 86. Driftstödnät enligt något av krav 83-85, kännetecknat av att nämnda första och andra objekt är belägna i varsitt första resp. andra delsystem.Operating support network according to any one of claims 83-85, characterized in that said first and second objects are located in each first resp. other subsystems. 87. Driftstödnät enligt krav 86, kännetecknat av att för att möjliggöra laddning i det hanterade systemet av nämnda andra delsystem utan omladdning av nämnda första delsystem används dynamisk länkning.Operating support network according to claim 86, characterized in that in order to enable loading in the managed system of said second subsystem without reloading of said first subsystem, dynamic linking is used. 88. Driftstödsnät enligt krav 71, kännetecknat av att den generella driftstödhanteraren utifrån en representation av driftstödsinformationsmodellen kan interagera med ett hanterat system på sådant sätt att begrepp i driftstödsinformationsmodel- _ _ q* Fx u. 0.16 *NI 80 len transformeras till representationer och strukturer lämpliga för användning av en yttre användare, såsom ett fönsterhante- ringssystem, en databashanterare etc.Operating support network according to claim 71, characterized in that the general operating support manager, based on a representation of the operating support information model, can interact with a managed system in such a way that concepts in the operating support information model are transformed into representations and structures suitable for use by an external user, such as a window management system, a database manager, etc. 89. Driftstödsnät enligt krav 88, kännetecknat av att den generella driftstödhanteraren mjukvarumässigt skapar en intern representation av det hanterade systemets driftstödinformations- modell genom att tolka denna och presentera den för en yttre användare som på så sätt kan interagera med det hanterade syste- met.Operating support network according to claim 88, characterized in that the general operating support manager software-wise creates an internal representation of the managed support operating information model of the managed system by interpreting it and presenting it to an external user who can thus interact with the managed system. 90. Driftstödsnät enligt krav 89, kännetecknat av att den generella driftstödhanteraren utnyttjar den interna representa- tionen av det hanterade systemets driftstödinformationsmodell för att vidmakthålla modellens konsistens genom att analysera en yttre användares interaktionsmönster och vidta eller föreslå operationer mot det hanterade systemet.Operating support network according to claim 89, characterized in that the general operating support manager uses the internal representation of the managed system operating support information model to maintain the consistency of the model by analyzing an external user's interaction pattern and performing or proposing operations against the managed system. 91. Driftstödsnät enligt krav 89 eller 90, kännetecknat av att den generella driftstödhanteraren genom att tolka den in- terna representationen av det hanterade systemets driftstödsin- formationsmodell kan leda/föreslå operationer, i enlighet med konsistensregler, för en interaktiv användare av den generella driftstödhanteraren.Operating support network according to claim 89 or 90, characterized in that the general operating support manager by interpreting the internal representation of the managed system operating support information model can lead / propose operations, in accordance with consistency rules, for an interactive user of the general operating support manager. 92. Driftstödsnät enligt krav 71, kännetecknat av att den generella driftstödhanteraren innehåller funktioner som möjlig- gör att en yttre användare kan interagera med det hanterade systemet genom att manipulera representationer av det hanterade systemets driftstödsinformationsmodell.Operating support network according to claim 71, characterized in that the general operating support manager contains functions enabling an external user to interact with the managed system by manipulating representations of the operating support information model of the managed system. 93. Driftstödsnät enligt krav 92, kännetecknat av att den generella driftstödhanteraren innehåller en yttre representa- tionsenhet som omvandlar för den generella driftstödhanteraren interna representationer till representationer anpassade till en i förhållande till den generella driftstödhanteraren extern användare av t.ex. ett fönsterhanteringssystem, databashanterare etc.Operating support network according to claim 92, characterized in that the general operating support manager contains an external representation unit which converts internal representations for the general operating support manager into representations adapted to an external user of e.g. a window management system, database manager, etc. 94. Driftstödsnät enligt krav 92 eller 93, kännetecknat av att den generella driftstödhanteraren innehåller en modelltolk som kan tolka den generiska representationen av det hanterade systemets driftstödsinformationsmodel1.Operating support network according to claim 92 or 93, characterized in that the general operating support manager contains a model interpreter which can interpret the generic representation of the operating support information model 1 of the managed system. 95. Driftstödsnät enligt något av krav 92-94, kännetecknat av att den generella driftstödhanteraren innehåller en funktion som å-TQ 11-56 81 genom att tolka en intern representation av driftstödinforma- tionsmodellen kan skapa en eller flera syntaktiskt och seman- tiskt riktiga operationer som kan riktas mot det hanterade systemet.Operating support network according to one of Claims 92 to 94, characterized in that the general operating support manager contains a function which, by interpreting an internal representation of the operating support information model, can create one or more syntactically and semantically correct operations. which can be directed at the managed system. 96. Driftstödsnät enligt något av krav 92-95, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt mot driftstödsnätet som används för att ta emot händelser i det hanterade systemet och rikta operationer mot detsamma, och för överföring och åtkomst av den i det hanterade systemet lagrade representationen av driftstödsinformationsmodellen.Operating support network according to one of Claims 92 to 95, characterized in that the general operating support manager contains access interfaces to the operating support network which are used for receiving events in the managed system and directing operations towards the same, and for transmitting and accessing it in the managed operating system. the system stored the representation of the operational support information model. 97. Driftstödsnät enligt något av krav 92-96, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt som möjliggör att samma generiska representationer av hanterat systems driftstödsinformationsmodel1 kan skickas över olika typer av kommunikationsnät.Operating support network according to one of Claims 92 to 96, characterized in that the general operating support manager contains access interfaces which enable the same generic representations of the operating support information model 1 of the managed system to be transmitted over different types of communication networks. 98. Driftstödsnät enligt något av krav 92-97, kännetecknat av att den generella driftstödhanteraren implementeras enligt en modell, som innefattar funktionalitet för att kunna utnyttja representationen av det hanterade systemets driftstödinforma- tionsmodell och göra transformationer till representationer lämpliga för en yttre användare utan att någon extra/ny informa- tion tillförs representationen av driftstödsinformationsmodellen utöver det som är specificerat och lagrat i det hanterade syste- met.Operating support network according to any one of claims 92-97, characterized in that the general operating support manager is implemented according to a model, which includes functionality to be able to use the representation of the managed system operating support information model and make transformations into representations suitable for an external user without any extra / new information is added to the representation of the operating support information model in addition to what is specified and stored in the managed system. 99. Driftstödsnät med minst ett driftstödsystem och minst ett hanterat system, för telekom- eller öppna system, varvid nämnda hanterade system innehåller fysiska och/eller logiska resurser, som av driftstödsystemet betraktas och hanteras som styrda objekt i form av databilder av resurserna, och varvid drift- stödsystemet för sina mot det hanterade systemet riktade opera- tioner utnyttjar en driftstödsinformationsmodell av det hantera- de systemet, vilken innehåller en till driftstödsystemets ar- betssätt anpassad beskrivning av alla styrda objekt, känneteck- nat av en generell driftstödhanterare, som innehåller funktioner som möjliggör att en yttre användare kan interagera med det hanterade systemet genom att manipulera representationer av det hanterade systemets driftstödsinformationsmodell.99. Operational support networks with at least one operational support system and at least one managed system, for telecom or open systems, said managed system containing physical and / or logical resources, which are considered by the operating support system and managed as controlled objects in the form of data images of the resources, and the operating support system for its operations directed towards the managed system uses an operating support information model of the managed system, which contains a description of all controlled objects adapted to the operation of the operating support system, characterized by a general operating support manager, which contains functions such as enables an external user to interact with the managed system by manipulating representations of the managed system's operating support information model. 100. Driftstödsnät enligt krav 99, kännetecknat av att den generella driftstödhanteraren innehåller en yttre representa- 456 82 tionsenhet som omvandlar för den generella driftstödhanteraren interna representationer till representationer anpassade till en i förhållande till den generella driftstödhanteraren extern användare av t.ex. ett fönsterhanteringssystem, databashanterare etc.Operating support network according to claim 99, characterized in that the general operating support manager contains an external representation unit which converts internal representations for the general operating support manager into representations adapted to an external user of e.g. a window management system, database manager, etc. 101. Driftstödsnät enligt krav 99 eller 100, kännetecknat av att den generella driftstödhanteraren innehåller en modelltolk som kan tolka den generiska representationen av det hanterade systemets driftstödsinformationsmodell.Operating support network according to Claim 99 or 100, characterized in that the general operating support manager contains a model interpreter which can interpret the generic representation of the operating support information model of the managed system. 102. Driftstödsnät enligt något av krav 99-101, kännetecknat av att den generella driftstödhanteraren innehåller en funktion som genom att tolka en intern representation av driftstödinfor- mationsmodellen kan skapa en eller flera syntaktiskt och seman- tiskt riktiga operationer som kan riktas mot det hanterade systemet.Operating support network according to one of Claims 99 to 101, characterized in that the general operating support manager contains a function which, by interpreting an internal representation of the operating support information model, can create one or more syntactically and semantically correct operations which can be directed at the managed system. . 103. Driftstödsnät enligt något av krav 99-102, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt mot driftstödsnätet som används för att ta emot händelser i det hanterade systemet och rikta operationer mot detsamma, och för överföring och åtkomst av den i det hanterade systemet lagrade representationen av driftstödsinformationsmodellen.Operating support network according to any one of claims 99-102, characterized in that the general operating support manager contains access interfaces to the operating support network which are used to receive events in the managed system and direct operations towards it, and for transmission and access of the managed operating system. the system stored the representation of the operational support information model. 104. Driftstödsnät enligt något av krav 99-103, kännetecknat av att den generella driftstödhanteraren innehåller accessgräns- snitt som möjliggör att samma generiska representationer av hanterat systems driftstödsinformationsmodell kan skickas över olika typer av kommunikationsnät.Operating support network according to one of Claims 99 to 103, characterized in that the general operating support manager contains access interfaces which enable the same generic representations of a managed system's operating support information model to be sent over different types of communication networks. 105. Driftstödsnät enligt något av krav 99-104, kännetecknat av att den generella driftstödhanteraren implementeras enligt en modell, som innefattar funktionalitet för att kunna utnyttja representationen av det hanterade systemets driftstödinforma- tionsmodell och göra transformationer till representationer lämpliga för en yttre användare utan att någon extra/ny informa- tion tillförs representationen av driftstödsinformationsmodellen utöver det som är specificerat och lagrat i det hanterade syste- met.Operating support network according to any one of claims 99-104, characterized in that the general operating support manager is implemented according to a model, which includes functionality to be able to use the representation of the managed system operating support information model and make transformations into representations suitable for an external user without extra / new information is added to the representation of the operating support information model in addition to what is specified and stored in the managed system.