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 series.

TMN considers all network nodes as network elements (NE). These network elements are designed as telephone exchanges and transmission or transport network products.

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 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 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.

Controlled objects are data images of such physical or logical resources such as lines, circuits, signal terminals, transmission roads, event logs, alarm reports, etc.

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.

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.

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.

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.

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.

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.

In the following, an account of deficiencies in TMN shall be given.

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.

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.

To be meaningful, the operational support system must know the information model of the managed system. This is called in TMN "shared management knowledge".

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.

All other parts of the information model, such as dependencies, the number of instances, etc., is stated informally as comments in natural language.

- Implementation and verification of the new information the model in the operational support system and the managed system.

Confirmation that operational support systems and managed systems are 479 456 5 adapted to the same information model, by performing approved test results.

Update of the operating support systems and managed systems existing network with this new version of the information model.

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.

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.

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.

Description of the invention.

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.

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.

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.

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.

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.

Various advantageous embodiments of the invention have obtained the characteristics specified in the respective dependent claims nen.

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.

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.

- The representation always corresponds to the model of it handled the system.

- Easy handling of the shared operating support knowledge "shared managementlknowledge ".

- Easy handling of system and network upgrades.

- 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.

A number of benefits come with making a specification of the information model in the form of a definable representation of the information model.

- 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.

- 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.

- 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.

- Early emulation and evaluation of the information model simplified, which makes the specification task easier.

- 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.

Description of the drawings.

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.

Description of embodiments.

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.

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.

When new resources are introduced into the managed system 10 need 4 (_21 .Yu UI (__) \ 12 only the model representation 6 is changed.

According to another feature of the invention, (stored) a representation of the information model in the managed system met.

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.

This specification is transferred to a compiler, by which implementation stub code and intermediate format for operational support information the tion model is generated.

The implementation stub code may then be refined manually and compiled to implement the managed system.

This implementation is then packaged together with intermediate the format of the operational support information model, to the charging package.

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.

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.

The creation of the charge packet is schematically shown in Fig. 2.

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".

According to step 18, the controlled object is implemented in C ++.

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.

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.

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.

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.

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.

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.

The block diagram in Fig. 3 shows the basic construction blocks of the architecture for the operational support function.

This 40-unit operating support system includes it general operating support manager 42 with a user interface 44.

In this interface, all controlled objects of the managed the system is inspected and modified.

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.

The managed system denoted by 48 includes a general one agent 50, which terminates the operating support protocol.

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, 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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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).

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.

The operational support manager's view of the two systems is shown in Fig. 9.

It is the same general operating support manager that is used and it interprets the model representations in system S1 and system S2.

Systems S1 and S2 operating support information model1 of subscriber numbers are different.

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.

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.

The framework is carried out through a rigorous and formal separation of the resource representation (model) and the actual resource.

The resource representation is interpreted by a software unit called operating support managers.

The operational support manager unit shall not need to have any special resource information in advance, ie. before it has started to work.

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.

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.

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.

Here, a more detailed account of the illustrations shown in Fig. 5 made interfaces are given.

Access interface for model.

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.

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.

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.

The interface in question has the following operations. 1 - connect_to_representation 2 - tolka_representation Resource access interface.

This interface is used to perform management operations against the real resource. Operations in this interface is often implementation dependent.

Operations: 1 - perform_operation (open / read / write / search etc.) 2 - transform_event.

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.

Operations: 1 - check_access 2 - restrict_access Information interface for resource capacity.

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.

Operations: 1 - export_possibility 2 - multiplex_possibility.

The controlling operating support manager.

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.

The representation.

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.

The representation can be used to feed more or less intelligent software with the necessary information to perform operational support operations.

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.

Old and new technology can coexist in the management domain.

In a telecom network, for example, equipment (resource units and operational support units) are introduced in one or more discrete activities.

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.

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).

Here it will now be explained how the separation described above model is used in the design of governing operating called.

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.

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.

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.

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.

- Other computers / computer systems.

'- Databases.

- A unit in the operating support domain itself. The Operational Support Manager can in other words used as a governing and decision-making unit.

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.

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.

The actual managed resource (mySubDir) is still in valid permit and no attempt has been made to perform one invalid operation.

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.

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.

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.

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).

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.

Such relationships form part of the operational support management model. the domain (for example, a subscriber directory number has a relationship to LIC).

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.

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.

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.

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.

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.

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.

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.

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.

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.).

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.

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.

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.

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.

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.

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.

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.

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; 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; 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 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 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 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.

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.

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.

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.

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.

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.

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.

// 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.

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.

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.

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.

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.

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.

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.

Here is now an account of how an operating support system records and interprets model information stored in a managed system.

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.

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.

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.

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 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.

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.

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.

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.

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.

Further explanation can be taken from the embodiment, as now described below with reference to Figs. 24-28.

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.

The above three steps are illustrated in Fig. 24. 4. Buffer >> local_MIM; Link.myAttList; // copy is filled in with formation.

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.

Fig. 25 illustrates how the operating support system derives the punch data from link A. 5. get (Link, A, all); read all attribute values.

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.

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 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.

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.

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.

- 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.

- The robustness during operation is improved because only leading to permissible transfers of licenses in the systems are accepted.

- Early emulation and evaluation of operational support information the part is facilitated, which makes the specification task easier.

- 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.

Here, first possible conditions must now be defined.

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.

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.

From the specification given in Fig. 30, line 1, it appears that UI 46 there could be managed objects of the class Subscriber.

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.

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.

The potential attribute values are determined by the type of attributes according to Fig. 31, rows 24, 28, 32, 37, 41.

Here now follows a description of how possible operations defined.

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.

The create operation creates a new instance of a specified class of controlled objects.

The delete operation removes controlled objects.

The write operation changes the value of an attribute of an instance of a class of controlled objects.

The method operation calls a method in an instance of a class of controlled objects.

The read operation returns the value of an attribute of a instance.

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.

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.

The write operation is optional and is specified as defined they an attribute as updatable.

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 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.

This managed object is defined as not having any delete or create operation, line 65.

Here now follows a description of how permitted combinations of operation / condition can be specified.

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.

In principle, there are two ways to specify these combinations. operations / permits, namely through preconditions and / or smiles final terms.

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.

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.

Lines 79 and 80 in Fig. 33 show how this can be expressed.

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.

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.

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.

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.

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.

Row 134 in Fig. 36 shows how the second strategy could specified so that the managed system maintains its texture.

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.

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.

Here now follows a more detailed description of how the definition of entered condition after an operation takes place.

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.

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.

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.

The LockRequest method is in fact the method that should be used to achieve the desired effect.

Fig. 39 shows on lines 176-178 how this is specified.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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).

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.

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.

The description below partly repeats what has been said above reference to Figs. 30-40, although more generalized.

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.

The m2 method returns a value of type AreturnType, line 10.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

There may also be restrictions on the number of stops an object type.

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.

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).

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.

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.

Conditions can be used, for example, to limit the system on the database. Restrictions on permit transfer times can also be expressed.

Here is a more detailed description of how the implementation mechanisms can be specified.

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.

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.

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.

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.

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.

First, the final terms must be considered.

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.

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.

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.

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.

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.

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.

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.

Here, triggered operations and propagations will now be described. vase. .

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.

What is mainly of interest are the methods set0pState and propagateOpState, rows 198 and 203, respectively. Fig. 57 shows the implementation of these methods.

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.

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.

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.

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 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.

The advantages of the above are as follows.

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.

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.

The maintenance of the code is therefore considerably simplified.

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.

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.

The solution described here facilitates the implementation of dependencies between system components, which develop uncoordinated.

It is even possible to apply the solution to system components, which are compiled and loaded separately.

Here is a more detailed description of the case uncoordinated implementation of system components to be provided.

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.

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.

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.

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.

The construction process described in more detail below is reversible in two different contexts with similar problems.

The first problem relates to the reuse of library components.

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.

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.

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.

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.

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.

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.

The second problem relates to a layered system architecture lucky.

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.

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.

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.

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.

Above, two cases with similar problems have been described. Here shall now follow a description of how these problems can be solved.

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.

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.

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.

Avoid recharging the original object when loading the future objects are created with dynamic linking.

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.

Of course, the subscribing component must also be specified himself as a subscriber to MOstateComponent.

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.

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.

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.

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.

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.

The specification of the object Resourceß can be found in Fig. 71.

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.

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.

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.

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.

Fig. 74 shows the specification of ResourceA. ResourceA specified as being a subtype of UserObject (line 41).

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.

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.

The declaration file generated from the UserO specification The object in Fig. 72 is found in Fig. 75.

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.

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 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.

The advantages of the above are as follows.

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.

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.

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 Patent claims. 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. 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. 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. 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. 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. Operating support network according to claim 5, characterized in that binding of the final conditions can take place to methods and creation operations. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Operating 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 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. 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. 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. 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. 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. 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. ' 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. . 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. 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. Operating 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Operating 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 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. 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. 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. 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. 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. Operating support network according to claim 79, characterized in that for the construction of components containing attributes, events are generated when changing attribute values. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. . 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. 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. 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.