Tutorial en

A very simple case using the COINS Navigator

This tutorial is based on the technical note A very simple case (in Dutch) which demonstrates, using a very simple example (bench), the communication transactions between the building director and three different project roles: specifier, 3D designer and planner. The COINS Navigator is able to mimic this case for all the mentioned participators. The next zip-bestand contains all required resources in addition to the here discussed COINS containers and the successive CBIS states.

Inhoud

COINS Container A (Building director -> Specifier)

Create a new CBIM

Figure 1: Toolbar button New...
Figure 1: Toolbar button New...

Start the COINS Navigator and click on the toolbar button New... (figure 1).

Figure 2: Identification of the new model plus applied reference frames.
Figure 2: Identification of the new model plus applied reference frames.

Before creating the new model some additional data need to be specified (figure 2):

Entering the objects in layer 0

Figure 3: Create a new function.
Figure 3: Create a new function.

Now we can start with entering the objects in layer 0. First of all the function A facility for several persons to sit (figure 3).

Figure 4: Specification of name and user ID.
Figure 4: Specification of name and user ID.

After the creation of the function in layer 0 a generated name is shown: Function_1. This name can be modified at the right-hand side of the application window. Besides, a user code is added which will simplify the search for objects later on (figure 4).

Two functional requirements belong to this function:

  • Appropriate for at least three persons.
  • Strong enough to bear a load of 300 kg.
Figure 5: Linking a requirement to a function.
Figure 5: Linking a requirement to a function.

Creating a new requirement is done in a similar way. After changing the name and the user ID's (e.g. FR1.1 and FR1.2) the requirements must be attached to the function. This can be handled in the Specification tab panel. Select at Container function the appropriate function (figure 5).

There are also two general requirements:

  • Materials to be applied: concrete and glass.
  • Location: see document xxxx
Figure 6: Adjusting the requirement type for general requirements .
Figure 6: Adjusting the requirement type for general requirements .

A general requirement is specified in the same area as functional requirements. However, before the object creation the requirement type must be adapted (figure 6).

Figure 7: Selecting the general requirement type.
Figure 7: Selecting the general requirement type.

General requirements are independent of functions so this step can be skipped. On the other hand a more specialised requirement type can be specified. For the material requirement Aspect/Execution is selected en for the location Aspect/Environment (figure 7).

Figure 8: Application window after entering the function fulfiller Bench.
Figure 8: Application window after entering the function fulfiller Bench.

The building object itself is entered now. Bench is chosen as its name (figure 8).

Figure 9: Selecting the function to be fulfilled.
Figure 9: Selecting the function to be fulfilled.
Figure 10: Linking of a general requirement.
Figure 10: Linking of a general requirement.

First, the building object is connected to the function to be fulfilled. This can be settled in the Functions tab of the specification part of Bench (figure 9). Select the function and click on the Add button. The function will be added to the list of functions to be fulfilled.

Finally the building object is attached to the two general requirements. This is achieved in a similar way in the General requirements tab (figure 10).

Saving the model

Figure 11: Saving the CBIM on the local disk.
Figure 11: Saving the CBIM on the local disk.

Save the model as a file (benchA.owl, A because this is phase A of the case) on the local disk (figure 11).

Adding documents

The case also contains two guidelines which can be attached to the model as document references. A document is not related to a certain layer. For this reason it will be entered on the Index tab (left hand side of the window) under the Document tab.

Figure 12: Layer-independent objects.
Figure 12: Layer-independent objects.

Because the guidelines apply for the whole building object the document objects are linked to the top object Bench. Click on the Show documents button on the identification part of the physical object Bench (figures 13 and 14).

Figure 13: Opening the document references window for a specific object.
Figure 13: Opening the document references window for a specific object.
Figure 14: Adding document references to Bench.
Figure 14: Adding document references to Bench.

Generating a COINS Container

Figure 15: Exporting a COINS Container from the current CBIM.
Figure 15: Exporting a COINS Container from the current CBIM.

Currently the first COINS Container can be generated to be sent to the specifier (figure 15).

Figure 16: Specify the folder and the name of the COINS Container.
Figure 16: Specify the folder and the name of the COINS Container.

Use A.ccr as the name for this export (figure 16).

Figure 17: The content of the COINS Container can be inspected with a ZIP tool (here WinZip).
Figure 17: The content of the COINS Container can be inspected with a ZIP tool (here WinZip).

In this case no physical documents are available which explains that only the bim folder is filled. VISI software will send the COINS Container as an appendix of the VISI message to the specifier.

COINS Container B (Specifier -> Building director)

Importing the COINS Container

The specifier receives a VISI message with a COINS Container as appendix containing the CBIM of the previous chapter. To import the container click on the menu-option File/Import.... A file chooser will be activated to select the COINS Container concerned. In another file chooser the folder to extract the container can be specified (figure 18). If necessary one can create a new folder beforehand within the file chooser session.

Figure 18: Selecting a folder to extract the COINS Container.
Figure 18: Selecting a folder to extract the COINS Container.

Adding new objects

In the case the specifier activates a new layer (layer 1) to the model with two subfunctions:

  • Offering sitting accommodation [F1.1]
  • Sticking to the soil [F1.2]

and two corresponding function fulfillers:

  • Seating system [B1.1]
  • Foundation system [B1.2]

First he activates layer 1 (figure 19).

Figure 19: Selecting layer 1.
Figure 19: Selecting layer 1.

Next he enters the two functions and physical objects connecting function F1.1 to be fulfilled by physical object B1.1 and function F1.2 by physical object B1.2.

Figure 20: Selecting the parent-physical object.
Figure 20: Selecting the parent-physical object.

Finally the decomposition relations of the new physical objects must be specified. For both sub physical objects the parent object is selected in the specification part under the Decomposition tab (figure 20). In this case there is only one choice.

With this the specifier in this very simple example is done with his additions. According the manner shown in chapter 1 he generates a new COINS Container (B.ccr).

He links the container subsequently to a VISI message that reports that the assignment is completed and sends it to the building director.

COINS Container C (Building director -> Designer)

Merging CBIS with COINS Container B

Figure 21: Merging the two models.
Figure 21: Merging the two models.

The building director will not import the COINS container B because then the internal CBIS model would be overwritten. In the CBIS the two models must be merged. Within the COINS Navigator this situation can be simulated by loading first the original model (benchA.owl) and subsequently merging this model with the contents of COINS Container B. After loading benchA.owl with the menu-option File/Open file... the menu-option File/Merge... is selected (figure 21).

Figure 22: Entering the VISI message ID.
Figure 22: Entering the VISI message ID.

First the ID of the VISI message that accompanied the COINS container is asked (figure 22). In this tutorial something For this tutorial an arbitrary ID can be entered.

After the merge operation a log window appears with the encountered events (figure 23).

Figure 23: Summary of the events of the merging operation.
Figure 23: Summary of the events of the merging operation.

After the merge operation it appears that physical object Bench occurs twice: besides the original version (0), which is represented in grey in the COINS Navigator, a new version (1) is added represented in black (figure 24).

Figure 24: New version of physical object [B1] Bench.
Figure 24: New version of physical object [B1] Bench.

The new version for this physical object is the result of the analysis that the Bench has now child objects where the previous version did not. It doesn't matter that the relation was defined from child to parent because the decomposition relation is bi-directional (has an inverse relation).

All new and updated objects will refer to the VISI message that this change with its accompanying COINS container brought about (figure 25).

Figure 25: Document reference to the VISI message that is responsible for the change..
Figure 25: Document reference to the VISI message that is responsible for the change..

Generating the COINS Container for the designer

After acceptance (in the COINS Navigator by saving the CBIS model in a new file using File/Save as... in benchAB.owl) the building director can send out immediately the next assignment as COINS container C. Exporting a model will automatically filter out all expired object versions passing on only the current version of each object.

COINS Container D (Designer -> Building director)

Adding new objects

After importing the COINS container C the designer activates a new layer (layer 2) and adds a set of physical objects to record more detail for the function fulfillers of layer 1. In case of the seating system a Beam [B1.1.1] is added, while the foundation system is elaborated by two physical objects: Support left [B1.2.1] and Support right [B1.2.2]. After creation the physical objects are attached to their respective parents Seating system [B1.1] and Foundation system [B1.2].

Figuur 26: Object tree view
Figuur 26: Object tree view

Next the designer will link those physical objects to 3D representations. In this tutorial two different courses of action are described. First a method where the physical objects are coupled to an IFC model that was exported from a CAD system. For the second method parametrically defined components are used. You can choose which course to take or try both if you like<ref name="ftn1">A third possibility could define a separate IFC file for each physical object type and to link it via a catalogue part object. The catalogue parts are not configurable in this case.</ref>.

Linking 3D representations to a geometric model (IFC)

In this version physical objects will be linked to an IFC model.

Figure 27: Selecting the IFC 3D representation format.
Figure 27: Selecting the IFC 3D representation format.

First of all three 3D representation link objects are created in CBIM for both the beam as well as the supports. After creation of an 3D representation object in the Explicit3DRepresentation tab (in the index panel at the left hand side) the proper format (IFC) is selected under the Specification tab (figure 27).

To view the result of the link the 3D viewer window must be activated (figure 28).

Figure 28: Activating the 3D viewer window.
Figure 28: Activating the 3D viewer window.

The button ... starts a file chooser to select the desired 3D representation model file. Choose the file A very simple case.ifc. The file name is copied as the name of the link object. The 3D representation is presented in the viewer (figure 29).

Figure 29: Graphical representation of the file A very simple case.ifc.
Figure 29: Graphical representation of the file A very simple case.ifc.

The 3D representation link now refers to the whole IFC model. What we need is are direct links with the various parts of the model. To do this click on the first row of the objects table and subsequently on the button Select (figure 30).

Figure 30: Selecting an object in an IFC model.
Figure 30: Selecting an object in an IFC model.

In the 3D viewer al non-selected objects are presented in wire frame while the selected element remains solid (figure 31).

Figure 31: The selected IFC object.
Figure 31: The selected IFC object.

The unique identification or Globally Unique Identifier (GUID) of the IFC object is copied to refer unambiguously to this object (figure 32).

Figure 32: The Globally Unique Identifier (GUID) is copied as link target.
Figure 32: The Globally Unique Identifier (GUID) is copied as link target.

Rename the previously generated name for this 3D representation link in something more meaningful: Beam.

Repeat this recipe to create 3D representation links for the support objects and name them Support left and Support right respectively.

Figure 33: Selecting the second layer..
Figure 33: Selecting the second layer..

Next the physical objects can be attached to these 3D representation links. To realize this we return to the Main structure tab and select layer 2 (figure 33).

Next for each of the three physical objects the proper 3D representation link is specified in the Shape part of the Geometry tab (figure 34).

Figure 34: Connecting a physical object with its 3D representation..
Figure 34: Connecting a physical object with its 3D representation..

With a click on the Show button the link is presented in the 3D viewer. This facility is also available for function fulfillers located higher in the object tree, e.g. [B1.2] Foundation system in layer 1 (figure 35).

Figure 35: Visualization of the physical object Foundation system.
Figure 35: Visualization of the physical object Foundation system.

Both support objects, which together constitute this physical object, are now presented as solids.

This concludes the activities of the assignment of the designer. He generates a COINS container of the results (D.ccr).

Linking 3D representations via catalogue parts (PMO)

This section describes an alternative scenario to couple 3D representations. In this version we use components defined in PMO (of Product Modelling Ontology) format. This format supports parametric modelling and is particular appropriate to facilitate configurable catalogue parts.

Figure 36: Selecting the PMO 3D representation format.
Figure 36: Selecting the PMO 3D representation format.

First of all two 3D representation link objects are created for both the beamer as well as the supports. After creating a new 3D representation object in the Explicit3DRepresentation tab (on the Index panel at the left hand side) the proper format (PMO) is specified under the Specification tab (figure 36).

Figure 37: Activating the 3D viewer.
Figure 37: Activating the 3D viewer.

To present the result the 3D viewer window is activated (figure 37).

Figure 38: Graphical rendering of the file beam.owl
Figure 38: Graphical rendering of the file beam.owl

Clicking on the button ... starts a file chooser to select ad couple the desired 3D representation model file. First select the file beam.owl. The name of the file is copied as the name of the link object. The 3D representation is rendered in the 3D viewer (figure 38).

Figure 39: Graphical rendering of the file support.owl.
Figure 39: Graphical rendering of the file support.owl.

Create according to the same recipe a link object for the file support.owl (figure 39).

The PMO files beam.owl and support.owl are in their turn dependent from two other PMO model files: bench.owl and benchsupport.owl. Because those models will not automatically form part of the COINS container it is necessary to create document references for these files. For reasons of model connectivity it is required to connect bench.owl to beam.owl using a document reference and the same for benchsupport.owl and support.owl.

Figure 40: Coupling of a shape link to a catalogue part.
Figure 40: Coupling of a shape link to a catalogue part.

Because the 3D representation format is parametric it is a good idea to create also catalogue parts. Thus, create a new object under the CataloguePart tab and select the beam.owl 3D representation link as shape representation (figure 41).

Figure 41: Changing a default parameter value.
Figure 41: Changing a default parameter value.

Clicking on the Load-button will import the parametric definition.

After loading the parameters plus default values appear in the tab Properties. Here parameter values can be changed by double clicking the value cell and using the Enter key after the modification (figure 41). Let's change the W (Width) parameter in 0.8 m. The 3D viewer shows immediately the change (i.e. if the parameter value change has a rendering effect of course).

Figure 42: Creating a catalogue part instance for a physical object.
Figure 42: Creating a catalogue part instance for a physical object.

Next we need to couple the catalogue part to the physical object Beam. Select the physical object Beam (in layer 2) and activate the Catalogue parts tab under the Specification tab. Select the catalogue part beam.owl and create an instance for this physical object (figure 42).

Figure 43: Creating a locator for a physical object..
Figure 43: Creating a locator for a physical object..

The Properties tab show the actual parameter values. Those values are just informative and cannot be changed here.

Figure 44: Determining the actual parameter values..
Figure 44: Determining the actual parameter values..

Finally the 3D object needs to be positioned. We select the X/Y position in the origin and a translation of 0.75 m along the Z-axis, a primary orientation along the positive Z-axis and the secondary orientation along the positive X-axis. Create a locator in the Geometry tab of the Beam physical object (figure 44) and change the Z-translation te read 0.75 (m).

Create also a catalogue part for the support and adapt also the width to read 0.8 m (W=0.8) (figure 44).

Both [B1.2.1] Support left and [B1.2.2] Support right will be connected with the catalogue part support.owl. Explicit positioning is necessary (for else both supports would coincide). For the left support a locator object is created under the Geometry tab. The locator is initialized with the default values. The left support must be moved a little backwards. Modify the X component of the translation vector in -0.75 m.

The right support needs also a locator object. The left support needs to be moved forwardly: put the X-translation on 2.75 m. The left support needs also to be rotated around the Z-axis. Therefore the secondary X-orientation must be changed into -1. Because this rotation affects also the Y-translation this must be compensated: change the Y-translation in 0.8m.

Figure 45: Render the 3D representation from a certain function fulfiller.
Figure 45: Render the 3D representation from a certain function fulfiller.

Now select the top-physical object Bench and click the Show button at the bottom of the Geometry tab (figure 45).

Figure 46: 3D visualization of the bench model.
Figure 46: 3D visualization of the bench model.

After a few seconds the 3D viewer visualizes the 3D representation (figure 46).

This concludes the assignment of the designer. He generates a COINS container with the results (D.ccr).

COINS Container E (Building director -> Planner)

The building director first loads benchAB.owl, which reflects the state of the CBIS BIM at the moment that the assignment for the designer was sent. Then the central model is merged with COINS container D.ccr which contains the result of the design process. The result is (after acceptance) saved as benchABD.owl. Inspection shows that the physical objects at layer 1 now have new versions because of the extensions on layer 2. If the PMO version was chosen [B1] Bench will also have a new version because of the generated explicit 3D representation link.

The building director generates from the updated CBIS a new COINS container E.ccr as appendix to the assignment for the planner. Again only last versions for each object will pass on to the container.

COINS Container F (Planner -> Building director)

The planner adds in this example case 3 new objects to his CBIM:

  • [T001] Put in the left support
  • [T002] Put in the right support
  • [T003] Put in the beam

These tasks can be imported from a planning application (MS Project, Primavera) or directly entered in the COINS Navigator. Here we take the last option.

Figure 46: The Task-tab in the Index-panel. With the Load-button tasks from planning applications like MS-Project or Primavera can be loaded.
Figure 46: The Task-tab in the Index-panel. With the Load-button tasks from planning applications like MS-Project or Primavera can be loaded.

The planning task objects are created in the Task tab under the Index tab (figure 46).

Figure 47: Specifying the start and end dates of a task.
Figure 47: Specifying the start and end dates of a task.

Start and end dates can be entered in the specification part as well as which function fulfillers are involved.

The planner sends the result of his assignment in a new COINS container F.ccr to the building director..

Figure 48: CBIS physical objects in layer 2 after the merge operation with the planning data.
Figure 48: CBIS physical objects in layer 2 after the merge operation with the planning data.

The building director loads first the original CBIS state as recorded in benchABD.owl en merges the central model with the COINS container F.ccr. The result will show new versions for the physical objects in layer 2 (because of the new relations with the planning task objects).

Afkomstig van CoinsWiki NL, de Vrije Encyclopedie. "http://www.coinsweb.nl/wiki/index.php/Tutorial_en"
Personal tools