DE19910527A1 - System and method for object identification in distributed hierarchical systems, especially in automation systems - Google Patents

Abstract

The invention relates to a system and a method for identifying objects in distributed hierarchical systems, especially automation systems. The aim of the invention is to guarantee object identification during operations such as shifting, copying, renaming, etc. To this end, contexts for producing several indirection steps for the administration of identificators are introduced. This results in efficient methods for repairing broken links, whereby global central administration functions are not introduced.

Description

The invention relates to a system and method for objecti identification in distributed hierarchical systems, esp especially in automation systems.

Such a system and method comes in particular in the Be automation technology.

The invention has for its object an object identi operations such as moving, copying, renaming ensure, etc.

This object is achieved by a system with the in claim 1 given features or by a method with the in An solved 2 specified features.

The invention is based on the finding that previous solutions have a low stability and / or a high change effort. There are two basic identification mechanisms that can be used (and can also be combined). One method is based on the identification of objects by assigning a globally unique identifier for each object. This global identifier ensures that an object can be found regardless of its current location. This method has the following disadvantages:

• - Central administration: The procedure requires central ver administrative structures such as management of property identifi cators and conversion tables of the object identifiers the objects.
• - Poor support for distributed work: Through the need for central administration is becoming an issue  division of object sets, their separate processing and subsequent merger (keyword branch and merge) difficult.

In the second method, an object is identified by its relative position to another. This also determines how the object can be found. In contrast to the first method, one object does not have a unique identifier, but this depends on the respective output object that references the other. This means that no central administrative information is required. However, there are the following disadvantages:

• - Low stability: by using the relative position the identifier (or the Id tifiers) invalid when moving the object and that Object is no longer available (broken link).
• - High change effort: After the identifiers of an object have become invalid, they must be a kind of correction run can be corrected.

In the solution according to the invention, contexts become education several levels of instruction to manage the identificatio ren introduced. This results in efficient procedures for Repair broken links without the introduction of global, central administrative functions.

• - No central administration: administration is carried out via the Context hierarchy. That means that every context is all contains the necessary information.
• - Support for distributed work: the context hierarchy chie can be disassembled and reassembled as required. This makes branch-and-merge of projects problem-free feasible.
• - Little change effort: Due to the context hierarchy immediately clear where changes to identifiers after are to be carried out. The changes are only on the be context objects.

In the following the invention with reference to the in the figures illustrated embodiments described and he purifies.

Show it:

FIG. 1 is a block diagram to identify the Sachver halts: a client sees name, an object model ar beitet with Ids

Fig. 2 is a schematic representation for the assignment and assignment of object identifications as object IDs and

Fig. 3 is a schematic representation for moving an object with the designation "ES-Auto 1 ".

In the following, the process is described in the context of the OVA engineering object model (OVA = Open Distributed Automation). However, it can also be used for other object models. For a better understanding of the relationships, the context of the invention is briefly discussed below:
For every object there is an environment in which it is known. At OVA, this environment is modeled by context. Within a context, names and identifiers of all contained objects are known and unambiguous. As a rule, the context is determined by the entry point that a user chooses to edit his automation solution. Context information is available on every container object (ie an object that contains other objects) such as H-Container, Chart or Master. However, the smallest environment for a context is a document. In the case of an embedded object, the context information of the surrounding document is used. However, this also means that context information can be structured hierarchically. Deeper contexts are always part of the higher hierarchical context. In addition, other contexts that are not hierarchically related can be associated with any context. Then this context can access the information of the associated context. However, this association is unidirectional. With associated contexts, the (hierarchical) contexts are automatically associated.

The context information determines which objects in the Direc tory are registered. The content of the document belongs to auto matically to the same context; this applies in particular to linked or via a rule ("all objects in this ver drawing ", etc.) added objects.

The context is also the administrator of the context IDs. This will be described later.

Object identification

Since OVA uses a standardized procedure to respond to the To access data storage, it is necessary to si the objects more identifiable. The reason for this is that part of the data is structural information, for example wel ches ES car in which chart is, or which car with which is connected. This structural information is subject to Rules based on the implementation of the data model be viewed. With the current realization by the Use of the IStorage interface as an interface to the data maintenance, it is always possible to change this structure, without considering the data model. For example it is possible for a client, copy, move or rename perform operations on the IStorage interface, without an OVA data model server being involved. The brings with it the problem that inconsistencies arise can be corrected later by the user by hand must be asked.

Therefore, the question now is how the consistency can be produced as far as possible without requiring the developer of ES cars or OVA tools to make excessive efforts. Neither should these mechanisms show through to the parts of the API that are used by the OVA tools. A client application, for example, should always handle the ES auto name, not cryptic IDs (see FIG. 1).

Problematic actions

First of all, the actions must be highlighted, the potential ones Hide dangers. On the one hand, these are all unidirek tional relationships, and other actions related to the Da "walk past" model servers.

Unidirectional links

Unidirectional links are problematic, as there is one Action is not apparent that an inconsistency arises. For example, in a Word document via a link referenced to a file, and this file to a later one Renamed at the time, the Word document does not get any of this with and will not find the file again. This problem can only be eliminated by a central authority that knows where to find the file.

"Stupid" actions

Here actions are called stupid actions that without the knowledge of the data model can be carried out. As z. B. Umbe name an object via the IStorage interface (IStorage :: RenameElement). Such actions are standard data access is always possible. Here too one could central authority help to minimize the problem. Important is in both cases, above all, the error detection, and if possible troubleshooting.

Object ID moniker

As described above, the objects can be centralized Manage so that they are (almost) clearly identifiable are. Therefore, all objects are referenced via object IDs, from the central location, in our case the Active Directory service that can be resolved.

This ID is independent of all actions; she will be at the Object creation and then no longer changes,  as long as no other object with the same ID exists. This is only used when copying outside the data model happen.

Each container awards when creating an embedded one ten object a name.

FIG. 2 shows a schematic illustration for the assignment and assignment of object identifications as object IDs. These IDs, in Fig. ID1, ID2, ID3 and ID4, are stored with their container. This means that the hierarchy container knows ID1 and ID2, Chart 2 knows ID3. These IDs are only unique within the container at the top level. That means Chart 1 can start again with ID1. Now individual objects can be identified using a chain of IDs. For example, ES-Auto 1 is identified via / ID1! ID1. The interconnection from ES-Auto 2 to ES-Auto 3 (IDy) receives the following IDs:

IDy = / ID1! ID4! C → / ID2! ID3! D

IDy is now a kind of alias for the connection from ES-Auto 2 to ES-Auto 3 . This is stored in the hierarchically lowest possible container. In this case, this is the H container 1 , since both Chart 1 and Chart 2 are involved in the interconnection.

Only the two ES cars 1 and 2 are involved in the IDx interconnection; therefore the information on how IDx is resolved can be stored in Chart 1 . This procedure of keeping the information as local as possible has the advantage that this reference can be resolved even if only a partial context is opened. In such a partial context, all references, interconnections, etc. are known that remain within the context. All references to the outside (or from outside) cannot be resolved.

Context IDs vs. local IDs

As can be seen in the example above, there are two ver different types of IDs. Firstly, the local IDs, such as Example ID1, ID2,. . ., which is always only local to the container are known. On the other hand there are the context IDs which are in are valid within the entire current context Zen. Both IDs must be unique in their environment. The local at the container level, the context IDs context-wide.

Dissolve

For example, an ID must be resolved if the object is to be activated. For example, ES-Auto 2 will check its interconnections during a consistency check. For this, IDx and IDy must be determined. To do this, ES-Auto 2 asks the individual objects of the context. Since the interconnections are stored as monikers, a BindToObject () is sufficient from the point of view of the ES car:

Since the monikers in this case are ObjectID Mo the server for ObjectID monikers, i.e. the Context, asked about the object. He knows IDy because he is for is responsible for its storage and resolves it into its loading components on. The ParseDisplayName function extracts IDy and Source and determines that this is / ID1! ID4! c. Well who which the container asks recursively for this object.

This somewhat complicated procedure is advantageous because the (possible) interconnections are also available in the sub-contexts. In the example above, Chart 1 could also be chosen as the entry point (context). The IDx interconnection can then also be accessed. In this case, IDy is an external interconnection that is not available as long as the processor only moves in the context of Chart 1 .

Use / examples

Now the effects are shown with some examples. The actions are move, copy, delete and rename nen.

Move

Starting situation is a mistake! Reference source not found. Now ES-Auto 1 is moved from Chart 1 to Chart 2 (see Error! Reference source could not be found.). This is done in two different ways. On the one hand in an OVA tool, on the other hand past the data model ("stupid moving").

Moving in the OVA tool

If the move is triggered in an OVA tool, the servers of the data model take over the action and thus ensure that all references remain valid. The two charts are at play here as agitators. The MoveESAuto method is triggered in the source chart. You will be given the ES car and the target chart:

All necessary steps are now encapsulated in the MoveESAuto method. This is first copying the ES car in Chart 2 , then deleting the original car from Chart 1 and finally adjusting the IDs. Since such an action can only change the IDs up to the object on which the action was carried out, only this must be communicated to the context:

This method causes the context, all IDs that start with "ID1! ID1" begin to change to "ID2! ID4".

Fig. 3 shows a schematic representation for moving an object with the designation "ES-Auto 1 ".

"Stupid" move

The servers of the object model are not involved in "silly" copying. Therefore, the update of the IDs cannot be carried out at this time. To carry out such an action, it is sufficient to move the persistent data storage of ES-Auto 1 from the storage of Chart 1 to that of Chart 2 . When Chart 1 is opened, this ES-Auto 1 will no longer display and delete its entry for "ID1". When opening Chart 2 , the user will find that an ES car has been added to his data storage for which no ID has yet been assigned. Therefore, ES-Auto 1 is now assigned an ID. Furthermore, the references of ES-Auto 1 and the partners involved have to be replaced. In the case of bidirectional IDs, this is not a problem. If ES-Auto 1 is asked for its external references, it will return IDx. If the context is asked for this ID, it can only resolve a part ("ID1! ID4") immediately. At this point "ID1! ID1" is still empty. However, since the action was triggered by a check of ES-Auto 1 , this can be remedied (possibly after asking the user):

Copy

Both ways should also be examined when copying:

Copy in the OVA tool

If ES-Auto 1 is only copied, nothing can be changed in the references. Chart 2 must assign a new ID to the target ES-Auto (e.g. ID4). Furthermore, all external references of the new ES car should be deleted.

"Stupid" copying

If ES-Auto 1 is copied past the object model like when moving, 2 ES-cars refer to ES-Auto 2 . However, this is not a problem, since Chart 2 determines that ES-Auto 1 is not yet known to him (no ID). As with shifting, he will now assign a new ID and test the external references of the ES car. In this case, however, ES-Auto 1 also exists in Chart 1 . Therefore, this check will not return an error. It is therefore necessary to check whether the unknown ES car is part of the external reference. The code from above needs to be expanded a little:

Clear

The following steps apply when deleting an ES car:

Delete in the OVA tool

If the ES car is deleted, all references can also be deleted immediately. The context is informed that a certain ID is no longer valid. This can now pass on to all objects (after user inquiry) that have a reference to this ID that the ID is not valid. For example, if in error! Reference source not found. If ES-Auto 1 is deleted, the following code must be executed:

This call means that the context for all Part calls the RemoveExternalReference () method.

"Stupid" delete

There are two situations when stupidly deleting: either Chart 1 is opened first. This determines that there is no ES car for ID1. He now deletes his entry "ID1".

On the other hand, an object can try to resolve the reference (e.g. ES-Auto 2 ). Since this is not possible, the user is asked what happened to ES-Auto 1 and what should be done with the reference.

Rename

Renaming behaves like moving.

In summary, the invention thus relates to a system and Procedure for object identification in distributed hierarchies systems, especially in automation systems. For Ensuring object identification during operations such as moving, copying, renaming, etc. is suggested that contexts to form several levels of indirection to Management of identifiers will be introduced. Thereby he are efficient procedures for the repair of so-called "Broken Links" without the introduction of global, central Ver administrative functions.

Claims (2)

1. System for object identification in distributed hierarchies systems, especially in automation systems Means for the formation of several levels of administration identifiers of objects. 2. Procedure for object identification in distributed hierarchy chemical systems, especially in automation systems, in which the objects are used by several levels of management of identifiers.