DE10154858A1 - Method for distributed processing of a construction project using CAE, whereby a whole process is considered so that common working materials are ordered in a consistent manner for the whole project - Google Patents

Abstract

Method for distributed processing of a project in a construction processing process using CAE, whereby the whole process is considered and the common working material of the project required by the processors, e.g. architects, is considered together so that it can be ordered in a consistent manner.

Description

The invention relates to a method for the distributed processing of a project in Construction planning process with CAE. The method enables the synchronous and asynchronous processing of the shared working material of the project by several actors computing aids.

A number of different actors create a common one in the construction planning process Working material. Three cyclically repeating phases can be identified in this process. in this connection In a first phase, the actors form subsets of the common working material for your own editing. In the subsequent phase, these subsets become synchronous or processed asynchronously. Finally, the results are in the third phase of editing stored in the common working material.

A disadvantage with regard to ensuring consistency is that the construction planning process is carried out is characterized by its iterative character, in which the final solution as a result of Coordination processes only after the solutions in the individual have been changed frequently Specialist disciplines is achieved. In the case of available CAD systems, the actors communicate through the Exchange of CAD documents. Detecting the changes between two different ones Version levels of a CAD document is time consuming.

Available CAD systems do not have a general approach to modeling the Object relationships in the common working material. It is not possible to give the processor a To provide assistance in dealing with the effects of an object change. The visual Assessing the effects of changes on your own planning is prone to errors. The shared working materials are therefore almost always inconsistent.

The problem described is not solved by existing document management Systems (DMS) solved. Since a document consists of a set of objects, it is considered changed as soon as one of its elements changes. All of this change is in Related documents are affected, and potentially every element of their object sets.

The result is frequent and non-specific change notifications. Assessing the The effects of these changes are left to the user at the object level.

The invention has for its object to provide a method with which the quality of common working material of the planning process is sustainably improved by the support of the iterative processing steps of the process the consistency of the common working material is guaranteed.

According to the invention, the object is achieved with a method which the in claim 1 contains the specified characteristics.

Advantageous refinements are specified in the subclaims.

Detailed description of the invention

The invention is described in detail below. In Part 1 (p. 3-p. 10) the selected abstractions and in part 2 (p. 11-p. 33) for the distributed processing required operations are described.

The advantages achieved with the invention consist in particular in that holistic view and support of the planning process the consistency of the common Working material can be guaranteed.

Part 1 sets and structures introduction

Solutions for construction tasks are created with object-oriented Methods implemented in software. The resulting object models consist of a Set of objects and relationships between the objects together.

Project

In [3, p. 10] a project is called "... A summary of the quantities for a." specific application, such as a construction project. The objects of a project are Mintings of different classes. A particular object can be in multiple project quantities be included. Each object of the project has a unique name in the project. ".

of objects

The objects of all editors of the project are in the object set Ω of the Project saved. Each element of the set of objects is a persistent identifier assigned.

Object Version quantity

• - infolge der Beziehungen zwischen den Objekten können durch eine Änderung eines Objekts die davon abhängigen Objekte ungültig werden
• - im Planungsprozess dürfen aus Gründen der Rechtsverbindlichkeit so genannte Revisionsstände nicht mehr geändert werden

The attributes of once saved project objects may no longer be changed for the following reasons:

• - As a result of the relationships between the objects, changing an object can make the dependent objects invalid
• - In the planning process, so-called revision levels may no longer be changed due to legal bindingness

Any number of states of an object must therefore be storable in the project. Such a stored state of an object is called an object version or a version. The set of all object versions of the project is called M. The attributes of the object versions a _i ∈ M must be current. Each object version is assigned a unique persistent identifier. The mapping ω: M → Ω assigns an object a ∈ Ω to each object version a _i ∈ M. Geometrically, the object version and object are represented as nodes and the image as a dash-dotted edge directed from the object version to the object:

The set of attributes is to be divided between object and object version. The object versions saved in M must not be changed. The object therefore has all attributes whose value cannot be changed. An example of this is the class of the object, since it does not change as required. Example 1 Mapping the object version set M to the object set Ω

ω = {(a ₁ , a), (a ₂ , a), (a ₃ , a), (b ₁ , b), (c ₁ , c), (c ₂ , c)}

ω (a ₁ ) = a ω (a ₂ ) = a ω (a ₃ ) = a

ω (b ₁ ) = b

ω (c ₁ ) = c ω (c ₂ ) = c

object change

A relationship in the form of an object change can exist between two object versions a _j , a _k ∈ M with ω (a _j ) = ω (a _k ). An object change (a _j , a _k ) means that the object version a _{k was created} by changing the object version a _j . The object version graph shows an object version as a node and an object change (a _j , a _k ) as a dashed edge directed from a _j to a _k :

The original version of the object and the deleted object versions were not created by changing their predecessor. However, it is advisable to also consider these two cases as object changes. To do this, virtual object versions δ _i ∈ Δ must be introduced:

The object version a _i is the original version of the object a if the object change relationship (δ _i , a _i ) ∈ Δ × M exists. The object version a _l was deleted if the object change relationship (a _l , δ _l ) ∈ M × Δ exists.

Object version graph

The object versions of an object and the relationships between the object versions are represented geometrically as a graph with dashed edges:

The nodes of the graph are the object versions. The edges of the directed circle-free (A graph is called circle-free or acyclic, if the following applies: If there is a non-empty path from a _i to a _j, there is no non-empty path from a _j to a _i .) Object version graphs indicate the changes in the object versions. The only node of the graph without input edges (node a ₁ ) represents the original version of the object. (Since the original version is easy to recognize, the edge (δ _i , a _i ) ∈ Δ × M and the virtual object version δ _{i are} often omitted from the graph.) The starting edges of a node lead to the object versions developed from it. If there is only one output edge, this leads to a revision of this object version. From nodes with several starting edges (node a ₁ ), several variants of this object version were developed (nodes a ₂ , a ₃ and a ₄ ). Nodes with several input edges bring variants together again (node a ₆ ). Deleted object versions must be marked in the graph (node δ ₁ ), since no new object versions should be derived from them.

Object Version relation

The mapping ω: M → Ω leads to unstructured Object version quantities. The relationships between the object versions are determined using the Object version relation V ⊆ M_Δ × M_Δ described.

M_Δ : = M ∪ Δ

Δ: = {δ_i| δ_i is a virtual object version}

An ordered pair of the object version relation describes a change relationship between two object versions. For example, the pair (a _i , a _j ) means that the object version a _{i has been changed} to a _j . It is advisable to also store ordered pairs in the object version relation for the original version and for deleted object versions. The virtual object versions δ _i ∈ Δ are used for this:

V: = {(a _i , a _j ) ∈ M _Δ × M _Δ | Version a _j is the successor of version a _i } = V _N ∪ V _A ∪ V _L

with the disjoint sets (In the following identifiers, N stands for new, A for old and L for deleted.)

V _N : = {(δ _i , a _j ) ∈ Δ × M | a _j is the original version of the object ω (a _j )} ⊆ V

V _A : = {(a _i , a _j ) ∈ M × M | a _j is the successor of a _i } ⊆ V

V _L : = {(a _i , δ _j ) ∈ M × Δ | successor of version a _i has been deleted} ⊆ V

Example 2 Object Version relation

The object version relation is given for the object version graph shown on page 5. The elements δ ₀ , δ ₁ ∈ Δ are virtual object versions. The original version was developed from δ ₀ .

V = {(δ ₀ , a ₁ ), (a ₁ , a ₂ ), (a ₁ , a ₃ ), (a ₁ , a ₄ ), (a ₂ , a ₅ ), (a ₃ , a ₆ ) , (a ₄ , δ ₁ ), (a ₅ , a ₆ ), (a ₆ , a ₇ )}

object relations

In [1] the problem of the description and handling of the Relationships between objects and the changes in structured object sets are dealt with. Analogously, the terms attachment and dependency are used in this document Object version sets applied. On this basis, the processing of subsets of a project described.

binding

A relationship in the form of a bond (a _i , b _j ) can exist between two object versions a _i , b _j ∈ M. A bond (a _i , b _j ) means that b _j is bound to a _i . In the binding graph, an object version is shown as a node and a binding (a _i , b _j ) as a solid edge directed from node a _i to node b _j :

• 1. Zum Berechnen der Attribute von b_j müssen Attribute von a_i gelesen werden.
• 2. a_i ist ein Element der Menge b_j. Die Menge gilt nämlich als geändert, sobald sich eins ihrer Elemente ändert.

An object version b _j is bound to the attributes of an object version a _i if at least one of the following conditions is met:

• 1. To calculate the attributes of b _j , attributes from a _i must be read.
• 2. a _i is an element of the set b _j . The quantity is said to have changed as soon as one of its elements changes.

dependence

Depending on an object version, an object version c _k ∈ M is called a _i ∈ M if there is at least one path from a _i to c _k in the bond _graph . Dependencies are represented by a solid arrow with an empty arrow head:

binding relation

If an object version c _k ∈ M is bound to an object version a _i ∈ M, then the ordered pair (a _i , c _k ) is an element of the binding relation B ⊆ M × M:

B: = {(a _i , c _k ) ∈ M × M | a _i binds c _k }

The relation H (B) ⊆ M × M [1] is calculated as the transitive envelope (see for example [2]) of the binding relation B ⊆ M × M.

H (B): = {(a _i , b _j ) ∈ M × M | b _j depends on a _i }

An object version must not depend on different object versions of other objects his. This requirement is based on an example from the software development process clarified. A function a () should have two calls to a function b (): this means that a () is dependent from b (). The interface of b () will be changed afterwards: The new version has one additional parameters. It has to be decided whether a () remains the original version of b () or whether a () should use the revised version of b (). But obviously it's not allowed to use different versions of b () in a ().

It is advisable to process subsets of a versioned system like an unversioned system. This is also only possible if object versions are not dependent on several object versions of other objects. To do this, both of the following conditions must be met:

Condition (1) is fulfilled if there is no object version that depends on several object versions of the same object. Condition (2) is met if there is no object version that depends on another object version of the same object:

The following applies formally:


With

B *: = B ∪ {(a _i , b _j )} Example 3 Invalid dependencies

In the support grid shown, the supports a _i and b _{i introduce} their left bearing force into the support c _i . On a _i and b _{i there} is a plate which transfers its loads symmetrically to both beams as surface load q. There are two object versions of the surface load q: The object versions q _i and q _j result from plates with different thicknesses. The system described is inconsistent since the carrier c _{i is} loaded by two different object versions q _i and q _{j of} the surface load q.

Part 2 Distributed editing operations

The object versions a _i ∈ M are processed in a distributed environment. The consistent processing of partial quantities of the project is described below.

Workspace

Changes and deliveries of existing object versions a _i ∈ M of the project can only refer to object versions derived from them. These are loaded for interactive editing in a private work environment of the planner, which is called workspace. The workspaces of all editors are disjoint in pairs. Only your own workspace can be changed. The other users' workspaces can only be read. For each object, a maximum of one object version may be stored in the workspace. At the end of processing, the results are discarded or saved as new object versions in the project.

Operation SELECTION introduction

The processing begins with the selection of the subset S ⊆ M to be processed by the user. However, not all object versions m _i ∈ M can be edited at the same time. On the one hand, it is useful to have the user edit a maximum of one object version per object. On the other hand, rules based on the binding relation B have to be fulfilled. Finally, it should be possible to select and edit further subsets in the project while editing a subset in the workspace.

• - Der Kreis b₁ hat den Radius r₁. Sein Mittelpunkt ist an den Punkt a₁ gebunden.
• - Durch Ändern des Radius r₁ des Kreises b₁ entsteht der Kreis b₂ mit dem Radius r₂. Der Mittelpunkt von b₂ ist weiterhin an den Punkt a₁ gebunden.
• - Der Punkt a₁ wurde verschoben und als a₂ gespeichert. Der Kreis b₃ bezieht sich auf den geänderten Mittelpunkt a₂. Der Radius ist weiterhin r₂.

The example of a structured object version set described below serves to illustrate this. The center of the circle b is bound to the point a. There are three object versions of circle b and two object versions of point a:

• - The circle b ₁ has the radius r ₁ . Its center is tied to point a ₁ .
• - By changing the radius r _{1 of} the circle b ₁ , the circle b ₂ with the radius r _{2 is created} . The center of b ₂ is still bound to point a ₁ .
• - The point a ₁ was moved and saved as a ₂ . The circle b ₃ refers to the changed center a ₂ . The radius is still r ₂ .

The definition of the selectable object version set is

• 1. Stellt sicher, dass maximal eine Objektversion eines Objekts selektiert ist.
• 2. Regelt das Selektieren der Objektversionen, die von ml abhängig sind. Es sei y ∈ Ω ein Objekt mit den Objektversionen {y_i|ω(y_i) = y}. Eine Teilmenge der Objektversionen von y sei von m_i abhängig. Falls Objektversionen von y selektiert werden, dann sind nur von m_i abhängige Objektversionen y_i mit (m_i, y_i) ∈ H(B) erlaubt. Beispielsweise sind für die auf Seite 11 dargestellte Menge M bei selektierter Objektversion a₁ nur die Mengen S = {a₁}, S = {a₁, b₁} und S = {a₁, b₂} erlaubt. Die Mengen S = {a₁, b₁, b₂}, S = {a₁, b₁, b₃} und S = {a₁, b₂, b₃} sind ungültig und werden durch die erste Bedingung ausgeschlossen, da hier mehr als eine Objektversion pro Objekt selektiert ist.
• 3. Regelt das Selektieren der Objektversionen, von denen ml abhängig ist. Es sei y ∈ Ω ein Objekt mit den Objektversionen {y_i|ω(y_i) = y}. Wenn das geordnete Paar (y_s, m_i) ∈ H(B) mit ω(y_s) = y ∧ m_i ∈ S existiert, so ist ml von der Objektversion y_s abhängig. Falls Objektversionen von y selektiert werden, dann ist nur die Objektversion y_s erlaubt. Beispielsweise sind für die auf Seite 11 dargestellte strukturierte Objektversionsmenge bei geladener Objektversion b₂ nur die Mengen S = {b₂} und S = {a₁, b₂} zugelassen.
• 4. Stellt sicher, dass keine Objektversion eines bereits geladenen Objekts selektiert wird (W_Δ und V werden bei der Beschreibung der Bearbeitung auf Seite 18 definiert).

The conditions (1) to (4) of this definition are explained below:

• 1. Ensures that a maximum of one object version of an object is selected.
• 2. Controls the selection of object versions that depend on ml. Let y ∈ Ω be an object with the object versions {y _i | ω (y _i ) = y}. A subset of the object versions of y is dependent on m _i . If object versions of y are selected, then only m _i y _i dependent object versions with (m _i, y _i) ∈ H (B) are allowed. For example, for the set M shown on page 11 with selected object version a _1, only the sets S = {a ₁ }, S = {a ₁ , b ₁ } and S = {a ₁ , b ₂ } are allowed. The sets S = {a ₁ , b ₁ , b ₂ }, S = {a ₁ , b ₁ , b ₃ } and S = {a ₁ , b ₂ , b ₃ } are invalid and are excluded by the first condition, since more than one object version is selected here.
• 3. Controls the selection of the object versions on which ml depends. Let y ∈ Ω be an object with the object versions {y _i | ω (y _i ) = y}. If the ordered pair (y _s , m _i ) ∈ H (B) exists with ω (y _s ) = y ∧ m _i ∈ S, ml depends on the object version y _s . If object versions of y are selected, only the object version y _{s is} allowed. For example, only the sets S = {b ₂ } and S = {a ₁ , b ₂ } are permitted for the structured object version set shown on page 11 when the object version b _{2 is} loaded.
• 4. Ensures that no object version of an already loaded object is selected (W _Δ and V are defined in the description of the processing on page 18).

Example 4 Selectable subsets of a structured object version set

For the structured object version set shown on page 11, the elements of the following set system are selectable subsets S ⊆ M:
{{a ₁ }, {a ₂ }, {b ₁ }, {b ₂ }, {b ₃ }, {a ₁ , b ₁ }, {a ₁ , b ₂ }, {a ₂ , b ₃ }}

An object version of the point or an object version of the circle may be selected alone become. However, if an object version of the point and an object version of the circle are selected both object versions must belong together.

LOAD operation Load object versions

Existing object versions a _i ∈ S ⊆ M of the project may not be changed as required. Therefore, the workspace has a lot of W with changeable object versions. Loading object versions means that for each a _i ∈ S a new object version a _{j is} created and entered in W. The ordered pair (a _i , a _j ) is in the machining relation V ⊆ S × W entered:

W: = W ∪ {a _j }

V : = V ∪ {(a _i , a _j ) ∈ S × W | successor version a _j of a _i is loaded}

Loading ties

The elements from W are related to each other and to elements from M. The bindings of the workspace are in relation B ⊆ (M ∪ W) × W entered. Since the elements of M cannot be changed, on the other hand, however, no elements of M can be bound to elements of W. The loading of bindings does not require manual intervention by the user - after loading object versions, the corresponding bindings are loaded according to the following regulation.

• 1. Die Bedingung stellt sicher, dass für die Bindung (x_k, y_l) ∈ B bei selektierter bindender und gebundener Objektversion x_k, y_l ∈ S eine neue Bindung (a_i, b_j) ∈ B erzeugt wird:
  
  
  
• 2. Die Bedingung stellt sicher, dass für die Bindung (a₁, y_k) ∈ B bei unselektierter bindender Objektversion a₁ ∈ M ∧ a_i ∉ S und selektierter gebundener Objektversion y_k ∈ S eine neue Bindung (a_i, b_j) ∈ B erzeugt wird:
  
  
  
• 3. Für die Bindung (x_j, y_k) ∈ B wird bei selektierter bindender Objektversion x_j ∈ S und unselektierter gebundener Objektversion y_k ∈ M ∧ y_k ∉ S keine neue Bindung erzeugt. Die gebundene Objektversion y_k ∈ M wird damit zu einer überholten Objektversion (in Überholte Objektversionen modernisieren auf Seite 28 definiert):
  
  
  
• 4. Beim Laden von Objektversionen muss die Menge W des Workspace nicht unbedingt leer sein. Dieser Fall liegt nämlich dann vor, wenn nach dem erstmaligen Laden weitere Objektversionen geladen werden.
  Die Bedingung (4.1) stellt sicher, dass für die Bindung (y_k, b_j) ∈ B bei selektierter bindender Objektversion y_k ∈ S und gebundener Objektversionen b_j ∈ W eine neue Bindung (a_i, b_j) ⊆ W × W erzeugt wird. Die Relation (4.2) beschreibt die zu entfernenden Bindungen.
  
  
  Fall (4.1) entsteht durch das Eintragen einer Bindung (a_i, b_j) ∈ M × W während der Bearbeitung im Workspace. Fall (4.2) resultiert aus dem Laden gemäß Fall (2). Die beiden Bilder machen deutlich, dass beide Fälle gleich zu behandeln sind.
• 5. Die Bedingung beschreibt für die Bindung (x_k, y_l) ∈ B den Fall einer unselektierten, jedoch bereits geladenen bindenden Objektversion x_k ∈ M ∧ a_i ∈ W ∧ (x_k, a_i) ∈ V und einer gebundenen selektierten Objektversionen y_l ∈ S. Die selektierte Objektversion y_l ∈ S wird als Objektversion b_j ∈ W geladen und durch die Bindung (a_i, b_j) ⊆ W × W an die bereits geladene Objektversion a_i ∈ W gebunden.
  
  

When loading bindings, new ordered pairs must be placed in the binding relation B entered and existing ordered pairs are removed from it. The terms of this definition correspond to the cases explained below:

• 1. The condition ensures that for the bond (x _k , y _l ) ∈ B with a selected binding and bound object version x _k , y _l ∈ S a new bond (a _i , b _j ) ∈ B is produced:
  
  
  
• 2. The condition ensures that for the binding (a ₁ , y _k ) ∈ B with unselected binding object version a ₁ ∈ M ∧ a _i ∉ S and selected bound object version y _k ∈ S a new binding (a _i , b _j ) ∈ B is produced:
  
  
  
• 3. For the binding (x _j , y _k ) ∈ B, no new binding is generated if the binding object version x _j ∈ S is selected and the unselected bound object version y _k ∈ M ∧ y _k ∉ S. The bound object version y _k ∈ M thus becomes an outdated object version (defined in Modernizing object versions on page 28):
  
  
  
• 4. When loading object versions, the quantity W of the workspace does not necessarily have to be empty. This is the case if additional object versions are loaded after the initial loading.
  The condition (4.1) ensures that for the bond (y _k , b _j ) ∈ B with selected binding object version y _k ∈ S and bound object versions b _j ∈ W a new binding (a _i , b _j ) ⊆ W × W is created. Relation (4.2) describes the bonds to be removed.
  
  
  Case (4.1) is created by entering a binding (a _i , b _j ) ∈ M × W during processing in the workspace. Case (4.2) results from loading according to case (2). The two pictures make it clear that both cases should be treated equally.
• 5. The condition describes for the binding (x _k , y _l ) ∈ B the case of an unselected but already loaded binding object version x _k ∈ M ∧ a _i ∈ W ∧ (x _k , a _i ) ∈ V and a bound selected object version y _l ∈ S. The selected object version y _l ∈ S is loaded as object version b _j ∈ W and is bound to the already loaded object version a _i ∈ W by the binding (a _i , b _j ) ⊆ W × W ,
  
  

Object versions from W that are linked to object versions from M can be updated. The reason for this is that when a linked object is updated, the binding object versions are only used and not changed. For example, when the object version d ₂ ∈ W is updated, the binding object version c ₁ ∈ M is only read. Example 5 Loading object versions and bindings

The structured object version set shown is given:

M = {a ₁ , b ₁ , c ₁ , d ₁ , e ₁ , f ₁ , g ₁ , m ₁ , n ₁ , p ₁ , q ₁ }

V = {(δ ₀ , a ₁ ), (δ ₀ , b ₁ ), (δ ₀ , c ₁ ), (δ ₀ , d ₁ ), (δ ₀ , e ₁ ), (δ ₀ , f ₁ ) , (δ ₀ , g ₁ ), (δ ₀ , m ₁ ), (δ ₀ , n ₁ ), (δ ₀ , p ₁ ), (δ ₀ , q ₁ )}

B = {(a ₁ , b ₁ ), (c ₁ , d ₁ ), (e ₁ , f ₁ ), (m ₁ , n ₁ ) (p ₁ , q ₁ )}

W = {h ₂ , n ₂ , p ₂ }

V = {(δ ₀ , h ₂ ), (n _1, n ₂ ), (p ₁ , p ₂ )}

B = {(g ₁ , h ₂ ), (m ₁ , n ₂ )}

The highlighted object versions are selected as set S = {a ₁ , b ₁ , d ₁ , e ₁ , g ₁ , m ₁ , q ₁ } and loaded into the workspace:

After loading, the quantities and relations of the workspace are:

OPERATION operation introduction

Operations on quantities and relations of the workspace are carried out during processing. The machining relation introduced when object versions are loaded V is therefore expanded:

V : = {(a _i , a _j ) ∈ M _Δ × M _Δ | successor version a _j of a _i is loaded} = V _N ∪ V _A ∪ V _L

With

M _Δ : = M ∪ Δ
W _Δ : = W ∪ Δ
V _N : = {(δ _i , a _j ) ∈ Δ × W | a _j is the original version of the object ω (a _j )} ⊆ V
V _A : = {(a _i , a _j ) ∈ M × W | a _j is the successor of a _i } ⊆ V
V _L : = {(a _i , δ _j ) ∈ M × Δ | successor of a _i was deleted} ⊆ V

Change object version

An object version is called changed if at least one of its attributes has been changed. The elements of the crowd


are changeable. There can be both newly created object versions


as well as object versions loaded from M.


be changed. After changing an object version a _j ∈ W is not only a _j , but also all object versions dependent on a _{j are} {b _k ∈ W | (a _j , b _k ) ∈ H ( B )} out of date. The set of all object versions to be updated in an update is called change set A:

A: = {b _j ∈ W | b _j is not current}

After processing the loaded partial model, unchanged loaded object versions should not be saved for reasons of efficiency. A loaded object version must also be "saved" if it was deleted during editing. For this reason, entering the object versions to be saved in a change set is not possible. Instead, the associated ordered pairs of the machining relation V in the change relation A entered. Since no pairs are made during editing A carried out, the results to be saved are known at the end of processing. (An equivalent alternative is to enter the loaded object versions a _i ∈ M in a set. With this procedure, however, newly created object versions cannot be entered in the set: Newly created object versions must therefore always be saved.)

A : = V _N ∪ V _L ∪ {(a _i , a _j ) ∈ V _A | Attributes of a _j have been changed} ⊆ V

After changing the object version a _j ∈ W, A and A be updated as follows:

A: = A ∪ {a _j } ∪ {b _k ∈ W | (a _j , b _k ) ∈ H ( B )}

A : = A ∪ {(a _i , a _j ) ∈ V } ∪ {(x _i , x _j ) ∈ V | (a _j , x _j ) ∈ H ( B )}

Enter object version

New objects are created in the workspace. The set of all objects in the workspace is called Ω , The image ω : W → Ω assigns an object a ∈ to each object version a _j ∈ W Ω to. The new object version is entered in W.

Implementation of the operation:

Ω : = Ω ∪ {a} ω : = ω ∪ {(a _j , a)} W: = W ∪ {a _j }

A: = A ∪ {a _j } A : = A ∪ {(δ ₀ , a _j )} V : = V ∪ {(δ ₀ , a _j )}

Remove object version

Object versions can be out of the crowd


be carried out. Both newly created object versions


as well as object versions loaded from M.


can be carried out. The element a _j ∈ W is carried out of W. In the set of ordered pairs {(a _i , a _j ) ∈ M _Δ × W | a _j has to be carried out)} ⊆ V the second component a _{j is} replaced by a virtual object version δ _i ∈ Δ. All input and output edges of a _j in the bond graph are deleted.

Implementation of the operation:

Enter binding

According to the conditions for the validity of the context relation on page 8, the entry of a bond (a _i , b _j ) ∈ (M ∪ W) × W in B subject to the following condition:

In the above definition, the transitive envelope H (B ∪ B ∪ {(a _i , b _j )}) both of the bonds B of the workspace as well as the bindings B of the project. If the condition is fulfilled, then the ordered pair (a _i , b _j ) in B be entered. The object version b _j is handled like a changed object version.

Apply binding

The discharge of a bond (a _i , b _j ) ∈ B is not subject to any conditions. The object version b _j is handled like a changed object version.

update

After a change, a subset of the object version set is no longer current. The application carries out an update at appropriate times. An object version Update means to update all of their attribute values. Within an update, the Update carried out exactly once for each object version. It comes down to the right one Order because the object versions to which the object version to be updated is bound to be up to date. Calculating the correct order of objects an update is described in [1].

Only object versions of the change set a _j ∈ A need to be updated. An updated object version a _j is carried out from A after the update:

A: = A \ {a _j } Example 6 Machining relation V ⊆ M _Δ × W _Δ

The object versions a ₁ , b ₁ , d ₁ ∈ M are saved in the project. The object versions a ₁ and b ₁ are selected and loaded into the workspace as object versions a ₂ and b ₂ . The object version b ₂ is deleted. The object version c ₁ is newly created. Quantities and relations between project and workspace are:

M = {a ₁ , b ₁ , d ₁ } S = {a ₁ , b ₁ } W = {a ₂ , c ₁ }

V _A = {(a ₁ , a ₂ )} V _L = {b ₁ , δ ₁ )} V _N = {(δ ₀ , c ₁ )} V = {(a ₁ , a ₂ ), (b ₁ , δ ₁ ), (δ ₀ , c ₁ )}

DISCHARGE operation

Unloading means the discharge of ordered pairs (a _i , a _j ) ∈ M × W _Δ from the machining relation V , Bindings affected by this must be changed accordingly. Modified, carried out and unchanged object versions can be unloaded. (The user should be warned of the loss of his / her work before unloading modified or removed object versions.) Newly created object versions, on the other hand, cannot be unloaded: they can only be deleted. Unloading refers to a subset e the machining relation:

e : = {(a _i , a _j ) ∈ M × W _Δ | object version a _i should be unloaded}

The amount S ∈ W of the object versions to be unloaded and not deleted is:

The elements in W are related to each other and to elements in M. Unloading object versions does not require manual intervention when handling bindings. These are handled before unloading the object versions in accordance with the following regulation:

Relation (1) describes the binding pairs to be entered:

Relation (2) describes the binding pairs to be discharged according to the previous and following illustration:

The remaining operations are:

Operation MERGE introduction

If the same object version is edited and saved synchronously or asynchronously, object variants are created. For example, the object version graph for object version a ₁ shown below contains the object variants a ₂ , a ₃ and a ₄ :

Object variants must be able to be merged into a resulting object version. A merged object version has more than one input edge in the object version graph. In the object version graph shown above, for example, object versions a ₂ and a _{3 have been merged} to object version a ₅ . The merge can be broken down into three sub-problems:

object versions

• - die Objektversionen a₁ und a₂ werden zur Objektversion a₃ zusammengeführt
• - die Objektversion b₁ wird als Objektversion b₂ geladen
• - beide Objektvarianten von c₀ sind gelöscht worden, daher ist weder ein Laden noch eine Zusammenführung möglich

The set Z (a) ⊆ {a _i ∈ M | ω (a _i ) = a} should contain mergable object versions a _{i of} the object a. There can be several sets Z (a) for an object. The result of the merge should be the object version z _r ∈ W. For this, the edges {(a _i , z _r ) ∈ Z (a) × {z _r }} are in the machining relation V and enter the ordered pair (z _r , a) in the figure w. One speaks of a merging of object versions if the set Z (a) contains at least two elements:

• - Object versions a ₁ and a ₂ are merged to object version a ₃
• - Object version b ₁ is loaded as object version b ₂
• - Both object variants of c ₀ have been deleted, so neither loading nor merging is possible

attributes

The attributes of the resulting object version z _r ∈ W must be assigned values. However, the attribute values of z _r can often not be calculated from the attribute values of the merged object versions. For example, with the underlying two-valued logic, no resulting value can be calculated from different Boolean attribute values. An accepted attribute value can usually only be determined through manual intervention by the processor.

bonds

If the object versions to be merged are a _i ∈ Z nodes of the binding graph, the entry of the edges is required

{(x _i , y _j ) ∈ (M ∪ W) × W | x _i = z _r ∨ y _j = z _r } ⊆ B
in the binding graphs, as with the attribute assignment, usually a manual intervention by the processor. This is always the case if the object versions a _i ∈ Z to be merged bind different object versions or are bound by different object versions.

• 1. Wenigstens zwei Elemente müssen in Z eingetragen sein
• 2. Alle Elemente z_i ∈ Z müssen Objektversionen desselben Objekts sein.
• 3. Für jeweils zwei Elemente z_i, z_j ∈ Z darf es im Objektversionsgraphen keinen Weg (z_i, . . ., z_j) oder (z_j, . . ., z_i) geben. Würde ein Weg existieren, so wären z_i und z_j keine Objektvarianten, sondern Objektrevisionen.

Obviously, a user-accepted calculation of the attribute values and bindings for the merged object version z _r ∈ W based on a set of mergable object versions Z (a) is not possible without manual intervention. Therefore, the restriction also applies when merging that a maximum of one object version per object may be selected and loaded:


H (V) denotes the transitive envelope of the object version relation. Object versions z _i ∈ Z ⊆ M must meet the following conditions:

• 1. At least two elements must be entered in Z.
• 2. All elements z _i ∈ Z must be object versions of the same object.
• 3. For every two elements z _i , z _j ∈ Z, there must be no path (z _i ,..., Z _j ) or (z _j , _... , Z _i ) in the object version graph. If a path existed, z _i and z _{j would} not be object variants, but object revisions.

The combination of a set of object versions Z ⊆ M into a common object version z _r ∈ W is handled as follows:

The resulting object version z _r ∈ W was created by loading the object version x _i ∈ M. The edge (x _i , z _r ) becomes the machining relation V and - if entered - from the change relation A discharged. The newly generated edges (z _i , z _r ) ∈ Z × {z _r } are in V and A entered. The entries in the change relation A ensure that the result is saved even if z _{r is} not changed. Example 7 Mergable object versions

The elements of the following set system are mergable subsets of the object version graph shown:

Z ∈ {{a ₂ , a ₃ }, {a ₂ , a ₄ }, {a ₃ , a ₄ }, {a ₄ , a ₅ }, {a ₂ , a ₃ , a ₄ }, {a ₃ , a ₄ , a ₅ }} Example 8 Merging object versions

After loading the object version x _i ∈ M as z _r ∈ W the processing relation is:

V = {(x _i , z _r )}

After the merge:

V = {(z ₁ , z _r ), (z ₂ , z _r )} A = {(z ₁ , z _r ), (z ₂ , z _r )}

MODERNIZE Operation Obsolete object versions

Given two elements e ₁ , f ₁ ∈ M with (e ₁ , f ₁ ) ∈ B, by creating a new object version of the binding element e ₂ from e ₁ , the object version f ₁ becomes an outdated object version:

Obsolete object versions are current, but they are bound to object versions, of which newer object versions exist. A versioned system for the planning process in construction must support outdated object versions. In practice it is for impossible for a specialist planner to change all of them after changing an object version Update object versions: The reasons for this assessment are the complexity of the Specialist models and above all respect for the data sovereignty of other specialist planners.

• - Nach einer Änderung der Schnittstelle von b( ) darf der Aufruf von b( ) in der ursprünglichen Version von a( ) nicht geändert werden: Wird diese Version von a( ) nämlich von einem Kunden eingesetzt, so kann sie von den Entwicklern nicht mehr rekonstruiert und damit auch nicht mehr korrigiert werden.
• - Die Änderung von b( ) muss unabhängig von der b( ) verwendenden Software durchführbar sein. So sind im Softwareentwicklungsprozess durch die Ableitung von Versionen Basis- Funktionalitäten unabhängig von den Applikationen manipulierbar. Erst wenn die Entwicklungen abgeschlossen sind, können die dann "überholten" Applikationen portiert werden.
• - Änderungen oder Fehlerkorrekturen von verwendeter Software dürfen nicht von jedem beliebigen Entwickler gemacht werden. In der Regel wird in einem solchen Fall eine Anforderung formuliert, die vom zuständigen Entwickler geprüft und ggfs. umgesetzt wird. Analog dazu kann durch Anfragen im Bauplanungsprozess die Datenhoheit des verantwortlichen Planers geachtet werden.

This should again be illustrated using the example from the software development process on page 8. A function a () uses a function b (): the function a () depends on b (). The interface of b () is changed later: The new version has an additional parameter. When changing b (), the following points should be noted:

• - After changing the interface of b (), the call to b () in the original version of a () must not be changed: If this version of a () is used by a customer, the developers can no longer use it reconstructed and therefore no longer be corrected.
• - The change of b () must be feasible regardless of the software using b (). In the software development process, by deriving versions, basic functionalities can be manipulated independently of the applications. Only when the developments have been completed can the "outdated" applications be ported.
• - Any developer may not make changes or error corrections to the software used. In such a case, a requirement is usually formulated, which is checked by the responsible developer and, if necessary, implemented. Similarly, the data sovereignty of the responsible planner can be respected by making inquiries in the construction planning process.

Obsolete object versions can be defined formally:

The set U ⊆ M of all outdated object versions is:

Modernize

The modernization of an obsolete object version f _{1 means} changing the bindings in such a way that they are only bound to object versions without a successor. Of course, you can also bind bound object versions to previous versions - for example, to undo a change.

The conditions to be followed when changing bindings are already for the entry and exit Discharge of bonds has been described.

Operation REDUCTION Reduction of the workspace

Newly created, changed and deleted object versions are saved in M after processing. However, unchanged object versions do not need to be saved in M. The unloading of unchanged object versions from W and the consistent handling of the bindings affected by this is called reducing the workspace. The following subset of the machining relation is to be unloaded:

In the change relation A the ordered pairs (δ ₀ , a _j ) ∈ Δ × W are entered for newly created object versions. Contains after the above set operation e only ordered pairs of unchanged object versions that were paid from M. Example 9 Reduction of the workspace

The structured object version set shown is given. The quantities and relations of the project are:

M = {a ₁ , b ₁ , c ₁ , d ₁ , e ₁ , f ₁ }

B = {(a ₁ , c ₁ ), (b ₁ , c ₁ ), (c ₁ , d ₁ ), (c ₁ , e ₁ ), (e ₁ , f ₁ )}

V = {(δ ₀ , a ₁ ), (δ ₀ , b ₁ ), (δ ₀ , c ₁ ), (δ ₀ , d ₁ ), (δ ₀ , e ₁ ), (δ ₀ , f ₁ ) }

The quantities and relations of the workspace are:

M = {a ₂ , b ₂ , c ₂ , d ₂ , e ₂ , f ₂ }

B = {(a ₂ , c ₂ ), (b ₂ , c ₂ ), (c ₂ , d ₂ ), (c ₂ , e ₂ ), (e ₂ , f ₂ )}

V = {(a ₁ , a ₂ ), (b ₁ , b ₂ ), (c ₁ , c ₂ ), (d ₁ , d ₂ ), (e ₁ , e ₂ ), (f ₁ , f ₂ )}

The object version c ₂ ∈ W is changed. The object versions d ₂ , e ₂ , f ₂ ∈ W dependent on c ₂ are also affected by this change. The change relation of the workspace is:

A = {(c ₁ , c ₂ ), (d ₁ , d ₂ ), (e ₁ , e ₂ ), (f ₁ , f ₂ )}

The workspace is reduced. The ordered pairs (a ₁ , a ₂ ), (b ₁ , b ₂ ) ∈ V can be unloaded because their attribute values were not changed during editing.

After the reduction, the quantities and relations of the workspace are:

W = {c ₂ , d ₂ , e ₂ , f ₂ }

B = {(a ₁ , c ₂ ), (b ₁ , c ₂ ), (c ₂ , d ₂ ), (c ₂ , e ₂ ), (e ₂ , f ₂ )}

V = {(c ₁ , c ₂ ), (d ₁ , d ₂ ), (e ₁ , e ₂ ), (f ₁ , f ₂ )}

A = {(c ₁ , c ₂ ), (d ₁ , d ₂ ), (e ₁ , e ₂ ), (f ₁ , f ₂ )}

SAVE operation introduction

• - die Ergebnisse seiner Bearbeitung werden verworfen
• - die Ergebnisse seiner Bearbeitung werden im Projekt gespeichert

Object versions are edited in the workspace. These are either newly created in the workspace or loaded as derived object versions from the project. Processing in the workspace therefore has no effect on the quantities and relations of the project. At the end of the processing, the user decides on one of the following two options:

• - The results of its processing are discarded
• - The results of its processing are saved in the project

Discarding the processing results means the quantities and relations of the workspace to empty.

to save

Since only current object versions are stored in the set M, the missing object versions must be updated after the reduction. The quantities and relations of the project are to be updated as follows after the update:

M: = M ∪ W Ω: = Ω ∪ Ω ω: = ω ∪ ω B: = B ∪ B V: = V ∪ V

embodiment

The invention is explained in more detail below using an exemplary embodiment. In the accompanying drawings Figs. 1 to 13 illustrate the working steps by means of a graph representation.

The example explains the support of the cooperation of three actors of the Planning process. It is an architect, a structural engineer and one Reinforcement planner. The aim is to ensure the consistency of the common working material.

The architect defines the geometry g of the column component. The structural engineer calculates the required reinforcement and documents it in the structural report. The reinforcement planner designs a suitable reinforcement b. The bonds {(g, s), (g, b), (s, b)} shown in FIG. 1 exist.

• - Die Bauteilgeometrie der Stütze liegt als ein Objekt g vor.
• - Die Statik liegt als Objekt s vor. Die Menge der Statik-Objekte ist auf die Menge der Bauteilgeometrien abbildbar.
• - Die Bewehrung b wird als Objektmenge mit den Bewehrungsstäben und den Bügeln gebildet. Die Mengenbildung ist zwar keine Voraussetzung, sie ist jedoch zur Lösung der vorliegenden Problemstellung zweckmäßig: Bei einer Änderung der bindenden Objekte g und s muss nämlich die gesamte Stützenbewehrung b vom Bewehrungsplaner kontrolliert und gegebenenfalls geändert werden. Die Menge der Bewehrungsobjekte ist auf die Menge der Bauteilgeometrien und auf die Menge der Statik-Objekte abbildbar.

The chosen model is based on the following assumptions:

• - The component geometry of the column is available as an object g.
• - The statics exist as object s. The set of structural objects can be mapped to the set of component geometries.
• - The reinforcement b is formed as an object set with the reinforcement bars and the stirrups. The quantity formation is not a prerequisite, but it is useful to solve the present problem: If the binding objects g and s are changed, the entire column reinforcement b must be checked by the reinforcement planner and changed if necessary. The set of reinforcement objects can be mapped to the set of component geometries and the set of structural objects.

• - Die Objektmenge des bindenden Dokuments ändert sich bei jeder Änderung eines darin enthaltenen Objekts. Abhängige Dokumente werden dadurch häufig ungültig und sind zu aktualisieren.
• - Nach einer Änderung ist nicht klar, welche Objekte des gebundenen Dokuments betroffen sind. Da potenziell jedes Objekt von der Änderung betroffen sein kann, muss der Planer alle Elemente der Objektmenge des Dokuments kontrollieren und gegebenenfalls aktualisieren.

Alternatively, other model configurations are also possible if this is expedient for the application. For example, other classifications can be selected. Models can also be created on the basis of documents. Since documents usually contain sets of objects, the use of documents mainly causes two problems:

• - The quantity of objects in the binding document changes each time an object contained therein is changed. Dependent documents are often invalid and have to be updated.
• - After a change, it is not clear which objects in the bound document are affected. Since every object can potentially be affected by the change, the planner must check all elements of the object set of the document and update them if necessary.

As shown in FIG. 2, the geometry of the component support is generated in step 1. The object version g ₁ of the column geometry is planned by the architect.

In step 2, the structural engineer produces the structural analysis s _{2 of} the support according to FIG. 3. It refers to the revision level [4] g _{1 of} the column geometry. The ordered pair (g ₁ , s ₂ ) ∈ B expresses that the statics are bound to the geometry of the column. The binding is entered in the model. After changing the column geometry, the amount of object versions that have been overhauled can now be calculated.

The type of notification to the structural engineer is not shown here. So can For example, when saving a new object version of the column geometry, those planners who have referred to the previous version, upon request they will be notified - for example by email (delivery obligation). It is also possible that the structural engineer is part of a Approval procedure [4] checks whether its static calculations are out of date (collect debt).

In step 3, as shown in Fig. 4, the reinforcement is planned. The reinforcement planner designs the column reinforcement as object version b ₃ . Two bonds (g ₁ , b ₃ ) and (s ₂ , b ₃ ) are entered because the construction of the reinforcement b ₃ relates both to the column geometry g ₁ and to the statics s ₂ .

FIGS. 5 and 6 illustrate step 4, with which the geometry of the support is changed. The architect loads the object version g _{1 of} the column geometry into the workspace as object version g ₄ . After loading, g ₁ and g _{4 have} the same dimensions. This state is shown in Fig. 5.

The architect changes the dimensions of the column cross section and saves. The state shown in FIG. 6 arises.

All object versions that relate to the previous version g ₁ are now obsolete. These are the object versions s ₂ and b ₃ .

Step 5 tries to modernize the reinforcement according to FIG. 7. The reinforcement planner has determined that reinforcement b _{3 is} outdated. It loads the object version b ₃ as object version b ₅ into the workspace for processing.

The reinforcement planner tries to adapt b ₅ to the changed column geometry g ₄ . He carries out the existing bond (g ₁ , b ₅ ) and the new bond (g ₄ , b ₅ ). However, since b ₅ is still bound to statics s ₂ , there is a path (g ₁ , s ₂ , b ₅ ) in the bond graph. The model is inconsistent because condition (1) on page 8 is not met. Object version b ₅ is namely dependent on the two object versions q ₁ and g ₄ of object g, as shown in FIG. 8.

The reinforcement planner recognizes that the reinforcement cannot be updated before the static calculation. It does not save, but discards the results of the processing. The state shown in FIG. 9 thus applies.

In step 6, the statics are to be modernized. The structural engineer notes that s ₂ is obsolete due to a change in the column geometry. It loads object version s ₂ as s ₆ into the workspace. s ₆ is still bound to g ₁ after loading, as shown in FIG. 10.

The structural engineer enters the existing bond (g ₁ , s ₆ ) and the new bond (g ₄ , s ₆ ). Then he changes the statics s ₆ according to the column geometry g ₄ . It is Fig. 11.

In step 7, the reinforcement is modernized. The reinforcement planner loads reinforcement version b ₃ as b ₇ . After loading, b _{7 is} still bound to g ₁ and s ₂ . This state is shown Fig. 12.

The bonds (g ₁ , b ₇ ) and (s ₂ , b ₇ ) are replaced by (g ₄ , b ₇ ) and (s ₆ , b ₇ ). Reinforcement b ₇ according to statics s ₆ is laid in column g ₄ . The result is shown in Fig. 13. Literature [1] PJ Pahl, K. Beucke; Newer concepts of CAD in construction: status and developments; Digital proceedings of the International Colloquium on Applications of Computer Science and Mathematics in Architecture and Building (IKM), Bauhaus University Weimar, 2000
[2] PJ Pahl, R. Damrath; Mathematical foundations of engineering informatics; Springer publishing house; Berlin; 2000
[3] PJ Pahl; Script data structures; Theoretical methods of construction and traffic engineering, Technical University Berlin; 2000
[4] K. Beucke; Script "CAE in the planning process"; Bauhaus University Weimar; Weimar; 2001

Claims (1)

1. Process for the distributed processing of a project in the construction planning process with CAE, characterized in that the overall process is considered and the common working material of the processor is reduced to the structured quantities mentioned below, namely - sets of objects and object versions - a mapping of the object version set into the object set for assigning the object versions to the objects - a binary relation in the object version set to form the change relationships - a binary relation in the object version set to form the binding relationships and that the processing is attributed to the interpretation and manipulation of these structured sets by one or more of the following operations for the distributed processing, namely - selection - Load - unload - merge - modernize - To reduce - To save - Edit consisting of creating object version, changing object version, deleting object version, creating binding, deleting binding and update and the consistency conditions for each operation are formally described with the rules of set theory.