COINS Navigator User Manual

COINS Navigator

Afbeelding:CoinsNavigator.gif

User Manual

Inhoud

Introduction

The COINS Navigator (formerly known as the COINS Test Tool) is a reference implementation to demonstrate the principles that lie at the bottom of the COINS standardization development. The application has the following features:

  • creating a C-BIM model
  • editing all aspects of a C-BIM model
  • loading/saving a C-BIM model
  • importing/exporting a COINS Container
  • simulate a COINS Building Information System (CBIS)
  • demonstrate the COINS version management system
  • merging C-BIM models
  • report generation in Excel or HTML format
  • switch between layer view and object tree view
  • build and link to COINS object libraries
  • link to external object libraries (CROW Cheobs, BuildingSMART IFD Library, ETIM)
  • specify and checking a Window of Authorization
  • link and visualize IFC models and/or PMO models
  • import planning data from Primavera of MSProject
  • link with the VISI building management data standard (under development)

The COINS Navigator can freely be downloaded, used and further distributed.

Installation

Figure 1: Installation folder content after extraction of the download ZIP file
Figure 1: Installation folder content after extraction of the download ZIP file
The COINS Navigator is a Java application. To be able to run the application Java needs to be installed on your computer. A recent version of Java is needed: version 6 or higher. Java can freely be downloaded from the following site: http://www.java.com. The Navigator makes use of some 32-bits DLL's. For this reason the 32-bits JRE version must be launched on 64-bits platforms!

The COINS wiki site (pagina Tools) will contain a link to the most recent version of the software. The installation file is a ZIP file that can be extracted in a folder of your choice.

Figure 2: Regional and Language Options.
Figure 2: Regional and Language Options.
The application can be started by double clicking of the coins-navigator.bat file icon.
Figure 3: Main application window.
Figure 3: Main application window.
The Dutch language menus will be shown if the language settings in the Windows menu control panel are selected as such. In all other cases the English version is presented.

Preferences / CoinsIO settings

After the first start-up the Navigator operates in "stand-alone" or "integrated" mode. This mode can be configured in the preferences dialogue which can be reached through the Help/Preferences... menu-item. The navigator can operate in client/server mode if a CoinsIO server is available. After specifying the server address (e.g. "http://<server>:8080/CoinsIO/services/CoinsIO") the connect button will be enabled and the connection can be established. This setting will be remembered for the next session.

Figure 4: Preferences dialogue.
Figure 4: Preferences dialogue.
Client/Server mode may especially affect I/O related actions in the Navigator. If the server operates on the same platform ("localhost") local file paths will still be available. A server in the company network may accept file paths on file servers in the same network. However, a remote server somewhere on the Internet will only accept web addresses or previously uploaded files.

The Navigator has a CoinsIO dedicated uploading function.

Figure 5: Upload menu item.
Figure 5: Upload menu item.
Figure 6: File upload dialogue.
Figure 6: File upload dialogue.

Preferences / other settings

The user name is initialized with the Windows login name and can be changed appropriately.

As soon as a model is loaded a default user and default baseline can be specified. These values are used when new information objects are created/modified to initialize the creator/modifier and baseline fields.

Check boxes are available to switch off expired objects from lists and to prefer web-links (if specified) over explicitly transferring documents in exported COINS Containers.

Model oriented functionality

Creating a new model

Figure 7: File-New menu item or toolbar button.
Figure 7: File-New menu item or toolbar button.
Figure 8: New model dialogue.
Figure 8: New model dialogue.
To start the procedure to create a new model click the File/New... menu option or the toolbar button with the same icon or by hitting the Ctrl-N key combination. Mind that this action could overwrite a possibly previous loaded model.

A pop-up dialogue window will appear to fill in the specifications of the new model. These specifications are:

Figure 9: After filling in the specifications the model can be created.
Figure 9: After filling in the specifications the model can be created.
  • Name
    A name for the new model. This name will be part of a URI Uniform Resource Identifier to create a globally unique identification of the model. This requirement slightly restricts the freedom to think up a name:
    • the name must start with a letter
    • no spaces
    • no special characters like '/', '&', '?', '@', '%' or '#'
  • Name space
    The name space in combination with the model name will form a globally unique identification. The server name and/or the pathname need not to exist. However, if the URI points to an existing web address the model can be loaded directly from the web.
  • Reference frames
    Check mark the reference frames that the new model is supposed to address.

If the name field is not empty the Create button will be enabled.

Loading a model from file

Figure 10: File-Open file menu item.
Figure 10: File-Open file menu item.
An existing COINS model on file can be loaded by clicking the File/Open File... menu item or the toolbar button with the same icon or by hitting the Ctrl-O key combination.

Mind that this action could overwrite a possibly previous loaded model.

A pop-up window presents a file chooser to select the file to be loaded. A filter presents only files of extension .owl, .xml or .rdf. Reset the filter to All files if the model is stored in a file with a different extension.

Loading a model from the web

Figure 11: File-Open URL menu item
Figure 11: File-Open URL menu item
An existing COINS model with an existing web address can be loaded directly by clicking the File/Open URL... menu item or the toolbar button with the same icon or by hitting the Ctrl-U key combination.

Mind that this action could remove a possibly previous loaded model.
A pop-up window will appear to specify the web address.


Figure 12: Open web file dialogue.
Figure 12: Open web file dialogue.

If the Navigator operates in client/server mode (CoinsIO server connection) the window will also show the available model files at the server side.

Linking to another model

Figure 13: Model info... menu item.
Figure 13: Model info... menu item.
A COINS model may link to another COINS model, e.g. to refer to a local library of catalogue items or to specify variant designs that refer to a common set of client requirements.
Figure 14: Model info dialogue window.
Figure 14: Model info dialogue window.
COINS library models can be both linked as web resource or as a locally stored file. In both cases their information objects are read-only. The Navigator represents library objects names in italic font.

Importing a COINS container

Figure 15: File-Import menu item.
Figure 15: File-Import menu item.
A COINS container can be imported by clicking the File/Import... menu item or the toolbar button with the same icon or by hitting the Ctrl-I key combination.

Mind that this action will overwrite a possibly previous loaded model.

A pop-up window will appear to control the container import procedure:

Figure 16: COINS container import dialogue.
Figure 16: COINS container import dialogue.
  • COINS container
    Specify the file location of the container. The button right will start a file chooser to make a selection.
  • Unpack directory
    Specify a folder to extract the COINS container.
  • Container contents
    A table presents the contents of the container. If desired the import procedure can be customized by check marking which documents to include in the import (by default all documents). This option may be handy for large documents in which the user has no interest. If the unpack folder already contains a document of the same name, date and size then the document is automatically excluded.

Report generation

Figure 17: File-Report menu item.
Figure 17: File-Report menu item.
By clicking the File/Report... menu item reports can be generated from the currently loaded COINS model.

A pop-up window will appear to control the generation. Two types of reports can be generated:

  • Excel format
  • Web page (HTML) format

Check marking determines the generation of either a spread sheet report or a textual document or both. The buttons at the right side start file choosers to aid the specification where to store the generated documents.

Figure 18: Generate report dialogue.
Figure 18: Generate report dialogue.

Browsing and editing functionality

Main application window lay-out

Figure 19: Main application window after the creation of a new model.
Figure 19: Main application window after the creation of a new model.
The main application window is approximately subdivided in two areas:
  • The left part presents various views on the model
  • The right part presents the content of a selected object (in the left part).

The model views are presented under the tabs:

  • Layers
    Objects that reside in the same layer. The layers are indicated by the numbered tabs at the left side. The layer view itself presents the typical Systems Engineering concepts:
  • Function
  • Requirement (and non-functional requirement if the Function Specification framework is enabled)
  • Function fulfiller (which covers both physical objects and spaces)
  • Performance
  • Verification
  • Object tree
    The function fulfiller objects presented in a tree view. Filters offer the facilities to extend the tree with document referencing objects and non-functional requirements (if the Function Specification framework is enabled). The panel below the actual object tree presents the functions (including inherited super functions) that a selected function fulfiller should fulfil. Again filters control the amount of information to show or hide the attached document referencing objects and functional requirements.
  • Index
    All objects that are not related to a specific layer.

The right part contains two tabs:

  • Identification
    This panel presents the identifying properties of an object.
  • Specification
    This panel presents the specific properties for the currently selected object type.

Layers panel

Figure 20: Layers view.
Figure 20: Layers view.
The layers panel presents all layer-oriented objects in the same layer. The layers are organized in a set of tabs that can be selected at the left side of the panel. Each layer shows separate sections for the Systems Engineering core classes:
  • Functions
  • Function fulfillers
  • Requirements
  • Performances
  • Verifications

Selecting an object in one of those lists will show the specifics of that object at the right side of the main application window.

New objects can be created by clicking the Create button at the bottom of each subsection. Sometimes beforehand a choice must be made between subtypes. For example creating a function fulfiller forces to make a choice between a Physical Object or a Space.

Figure 21: Subtype selection.
Figure 21: Subtype selection.
The Requirements section may contain both functional and general requirements. However, the general requirement option is only available if the Functional Specification framework for the current model is enabled.

Clicking the Create button adds a new object of the type indicated in the combo box to the list of the corresponding section. An automatically generated name is attached to the new object so that it can be placed in the list in alphabetical order (the alphabetical sorting operates on the combination of the User ID and Name fields). The generated name can be modified at the right part of the main window in the Name field under the identification tab.

Object names can be chosen freely, i.e. they may contain spaces and/or special characters. A name also need not to be unique (although it is good practice to do so of course): each object is identified by a globally unique ID. This GUID Globally Unique Identifier (or UUID) is not shown in the user interface.

Besides a name a user defined ID can be attached to an object. This User ID field property can also be chosen freely. It is common practice to use it for a systematic labelling of the object's position in the tree. For example B1 at top level; B1.1, B1.2, ... on the next level; B1.1.1, B1.1.2 for the children of B1.1 on the next level.

The verifications table is generated automatically for each (functional) requirement - function fulfiller combination. Initially, these verification objects will not appear in the saved model. Verification objects can be created explicitly by the user by clicking the create button or implicitly by check marking the result of specifying a verification method in the table row. If the requirement - function fulfiller combination is broken the corresponding verification row/object will also disappear.

Identification panel

The identification panel contains all non-specific properties of an object. The following properties are available for inspection or editing:

Figure 22: Identification panel.
Figure 22: Identification panel.
  • Name
    Name of the object. An object name can be chosen freely, i.e. it may contain spaces and/or special characters.
  • User ID
    User defined ID. A user ID is often used to attach a systematic label.
  • Library reference
    An optional link to an ID in an object library.
  • Description
    A more lengthy text to describe this particular object.
  • Baseline
    The baseline this object belongs to.
  • Documents
    The Show documents button pops up a window to show and edit the document links of this object.
Figure 23: Date editing.
Figure 23: Date editing.
  • Creation date
    The date this object was created. This field is automatically filled after the object's creation. However, it can be changed if necessary. A date can be changed directly in the text field or even more conveniently by clicking the button to the right which presents a small interface to select the desired date.
  • Creator
    The role/person/organization that created this object. Via the Help/Preferences... menu item this value can be pre-set with a default value for all new objects.
  • Modification date
    The last date this object was modified.
  • Modifier
    The role/person/organization that modified this object. Via the Help/Preferences... menu item this value can be pre-set with a default value for all modified objects.
  • Release date
    The last date the release status of this object has changed.
  • Status
    The current release status.
  • Version
    The version number of this object. At creation an object has version number 0 (often presented between parenthesis after the User ID/Name combination).
  • Expired
    If check marked this object is no longer valid.
Figure 24: Next version creation dialogue.
Figure 24: Next version creation dialogue.
  • Next version
    If enabled a button click will show the next version of this object (which is always expired). If no next version is available the user is asked if a new version must be created.

Object Tree panel

Figure 25: Object tree panel.
Figure 25: Object tree panel.
Another way to traverse the model is offered by the object tree view. This panel presents the tree structure of the function fulfillers which can be extended with attached document links and general requirement objects.

Selecting a function fulfiller presents the fulfilled functions in the lower part of the panel. Besides the directly fulfilled functions also super functions are presented in a kind of upside down display. This function tree can be expanded with attached document links and functional requirements.

Function fulfiller objects can be created and attached to a selected tree node by clicking the Add button or a right mouse button click.

Figure 26: Add a new function fulfiller to the selected parent object.
Figure 26: Add a new function fulfiller to the selected parent object.
The automatically generated object name can be modified in the identification panel at the right part of the main application window. The name can also be edited directly in the tree view by a triple click on the name tag (double clicking expands and collapses tree nodes). Pressing the Enter key finishes this local tree editing session. The User ID is placed between brackets. The version number is automatically appended between parentheses.
Figure 27: Drag 'n Drop.
Figure 27: Drag 'n Drop.
The object tree view is also particular handy for modifying the function fulfiller tree structure. This editing facility is implemented by drag-'n-drop. Select a tree node and hold the left mouse button pressed. Move the mouse to the node that will be the parent of the previously selected node. Release the left mouse button above this parent node.

After the move operation the necessary actions (detach from previous parent, attach to new parent, modify layer number) are performed automatically. Any attached to-be-fulfilled functions are detached and stay behind. This measure is necessary to guarantee the consistency of the model (more than one function fulfiller could fulfil the same function). For this reason the drag 'n drop facility is probably most valuable in the early stages of the model life cycle.

Index panel

Figure 28: Index panel.
Figure 28: Index panel.
The index panel collects all object that are not related to a specific panel. The interface is identical to the layer view panels: buttons for creating or deleting of objects of the specified type, cell editing of Name and User ID properties, row selection for presenting object data in the right part of the main application window.

Specification panel

The specification panel contains all object type specific properties. Therefore the description of this panel is broken down over the various object types.

Baseline

Figure 29: Baseline specification panel.
Figure 29: Baseline specification panel.
The baseline specification panel contains two property areas:
  • Baseline status
    Is the baseline open or closed?
  • Objects
    Which objects belong to this baseline?

Catalogue part

Figure 30: Catalogue part specification panel.
Figure 30: Catalogue part specification panel.
The Catalogue part specification panel contains six property areas:
  • Supertype
    A more general catalogue part from which this catalogue part inherits properties and subparts.
  • Amount
    The property type that is applied to express the amount that is calculated to deploy a technical solution.
  • Properties
    Property types plus values.
  • Subparts
    Assembly of other catalogue part objects.
  • Shape
    A reference to a 3D shape description.
  • Recipes
    Set of work items plus resources to produce a technical solution (only available if the Quantity estimation reference frame is enabled).

Document

Figure 31: Document specification panel.
Figure 31: Document specification panel.
The Document specification panel contains three property areas:
  • Type
    Document type: select a predefined type or enter a new one.
  • URI
    A web address (URL) or another way to uniquely address a document, for example an ISBN code (URN). The Browse button will start the default internet browser to inspect the web document.
  • File path
    The location of a document file on a local server. The Open button launches a default native application that is associated with the extension type of the document file.

Explicit 3D representation

Figure 32: Explicit 3D representation specification panel.
Figure 32: Explicit 3D representation specification panel.
The Explicit 3D representation specification panel has six property areas. The first three are identical to the areas of the document specification panel (Explicit 3D representation is a subtype of Document). Document type is now constrained to 3D shape representation formats, for example IFC. The URI may be an object ID inside the document (here an IFC global ID).The other areas are:
  • Objects
    Encountered objects that refer to 3D shape representations.
  • Properties
    Attached properties (if available) to a selected object.
  • Locator
    The locator (if available) of a selected object.

Function

Figure 33: Function Specification panel.
Figure 33: Function Specification panel.
The function specification panel contains three property areas:
  • Super-function
    The current function can be traced to be an elaboration of a more general function one layer higher. This feature is defined in the reference framework Functional Specifying.
  • Function fulfillers
    The function fulfillers that fulfil this function.Only function fulfillers in the same layer will be listed
  • Requirements
    The functional requirements attached to this function.Only requirements in the same layer will be listed.

Function fulfiller

The function fulfiller specification panel is subdivided into nine tabs: States, Functions, Performances, Decomposition, Tasks, Catalogue parts, Geometry, Terminals and Non-functional requirements. The more complex panels are discussed here.

States

Figure 34: States tab of the function fulfiller specification panel.
Figure 34: States tab of the function fulfiller specification panel.

The states tab of the function fulfiller specification panel shows the various facets of this function fulfiller with regard to life cycle stages (baselines). The selected stage (if any) filters the information presented at the Performances, Tasks, Catalogue parts and Geometry tabs to show only data related to this state. The actual selected state is shown in a titled border around all specification tabs.

The open/closed status of the baseline is reflected by the check marks in the Open column. State dependent documents are directly accessible using the buttons in the Document column.

The state rows have a fixed order according the their creation sequence in time. However using the arrow buttons this order can be changed.

Decomposition

Figure 35: Decomposition tab of the function fulfiller specification panel.
Figure 35: Decomposition tab of the function fulfiller specification panel.

The decomposition tab of the function fulfiller specification panel has three property areas:

  • Parent object
    The assembly object from which this function fulfiller forms a part.Only function fulfillers in the adjacent higher layer will be listed in the combo box.A function fulfiller in layer 0 cannot specify a parent object: the combo box will be disabled.
  • Children objects
    The part function fulfillers that form this assembly object.Only function fulfillers in the adjacent lower layer will be listed in the combo box.
  • Situation
    Specification in which space this function fulfiller is situated.In a hierarchy of spaces it is advisable to select the smallest space that conforms to this criterion.

Geometry

Figure 36: Geometry tab of the function fulfiller specification panel.
Figure 36: Geometry tab of the function fulfiller specification panel.

The geometry tab of the function fulfiller specification panel has two property areas:

  • Locator
    Specification of the location and orientation of this function fulfiller with respect to its parent object. An existing locator can be shared using the combo box. Mark that sharing a locator may lead to unexpected behaviour.If no locator object is available a new one can be created using the Create button.The description of the locator specification interface is discussed on page 21.
  • Shape
    Specification of the explicit 3D representation link object. Certain 3D representation formats can be viewed in the geometry window after clicking the Show button.

Terminals

Figure 37: The terminals tab of the function fulfiller specification panel.
Figure 37: The terminals tab of the function fulfiller specification panel.

The terminals tab of the function fulfiller specification panel has three property areas:

  • Terminals
    The specification of all the terminals of this function fulfiller. If the terminal is connected the function fulfiller at the other side with its applied terminal is also mentioned.
  • Locator
    The specification of the location and orientation of the selected terminal with respect to this owner function fulfiller.The description of the locator specification interface is discussed on page 21.
  • Shape
    The explicit 3D representation that defines the shape of this terminal.

Locator

Figure 38: Locator specification panel.
Figure 38: Locator specification panel.
The locator specification panel contains five property areas:
  • Translation
    Relative translation expressed in delta x, delta y and delta z values.
  • Primary orientation
    Primary orientation vector (default z-axis).
  • Secondary orientation
    Secondary orientation vector (default x-axis).
  • Min. bounding box
    Lower corner vertex of a bounding box.
  • Max. bounding box
    Higher corner vertex of a bounding box.

Property type

Figure 39: Property type specification panel.
Figure 39: Property type specification panel.
The property type specification panel contains three property areas:
  • Unit
    Specification of the unit associated to property values referring to this property type.
  • Value domain
    The set of possible values for this property type.
  • Template
    The super-type catalogue part to determine a family of all applicable catalogue parts that may act as a value for this (complex) property type. Complex property types are part of the reference framework Functional Specifying.

As good practice it is advisable to use the name field to specify the quantity name of this property. The user ID can be used to express the usual symbol for this type of property.

Requirement (functional)

Figure 40: Requirement specification panel.
Figure 40: Requirement specification panel.
The requirement specification panel contains four property areas:
  • Container functional
    The function this requirement belongs to.
  • Super-requirement
    The current functional requirement can be traced to be an elaboration of a more general functional requirement one layer higher. This feature is defined in the reference framework Functional Specifying.
  • Property type
    The property type and unit of the property value intervals. This feature is defined in the reference framework Functional Specifying.
  • Property value intervals
    The set of value intervals that compose the value domain the corresponding performance should obey. This feature is defined in the reference framework Functional Specifying.

Requirement (general)

Figure 41: Non-functional requirement specification panel.
Figure 41: Non-functional requirement specification panel.
The non-functional requirement specification panel has four property areas:
  • Type
    The aspect type of the non-functional requirement.
  • Super-requirement
    The current general requirement can be traced to be an elaboration of a more abstract general requirement one layer higher. This feature is defined in the reference framework Functional Specifying.
  • Property type
    The property type and unit of the property value intervals. This feature is defined in the reference framework Functional Specifying.
  • Property value intervals
    The set of value intervals that compose the value domain the corresponding performance should obey. This feature is defined in the reference framework Functional Specifying.

Task

Figure 42: Task specification panel.
Figure 42: Task specification panel.

The task specification panel has two property areas:

  • Execution
    The specification of the planned and actual start dates and end dates of the task. Besides the task type (constructing, destructing or unchanged) can be specified.
  • Function fulfillers
    The specification of all the function fulfillers that are affected by this task.

COINS Building Information System functionality

Introduction

The COINS Navigator offers functionality to emulate a Building Information System: the information system that manages the shared project model under control of the building project director. In contrast with many other BIM standards COINS explicitly addresses the process that build up a BIM and the way this can be organized in a typical building project.

Figure 43: The information flows to build up a COINS BIM.
Figure 43: The information flows to build up a COINS BIM.
In COINS the BIM is hosted by a COINS Building Information System (CBIS). The various contributors to the BIM do not operate directly on this shared model. They are invited by the building project director to work on specific task in an assigned area of the BIM. This modelling area supplemented with additional documents and data necessary to fulfil the task is copied to a cabinet file: a so-called COINS Container. This information package is attached to a formal assignment (according the VISI standard for building project management data) and sent to the executor of the task. The executor will complete his task by updating his modelling area within the modelling freedom granted by the assignment in the so-called window of authorization. After receiving the task result in a new COINS Container the building project director will carry out some acceptance tests (including the validation of the window of authorization). If the tests are passed satisfactory the updated modelling area is merged with the central BIM.

The COINS Container

The COINS Container is the central means of communication for object related content between the various users/contributors of BIM data. Physically the container is a common Zip file with a predefined folder structure. At this stage three folders are recognized:

  • bim
    In the bim folder the CBIM (sub)model can be found.
  • doc
    The doc folder will contain all associated documents referenced from the CBIM in the bim folder. Here we may find 3D representation files, text documents, spreadsheets, etc.
  • woa
    The woa folder is reserved for the window of authorization description file called woa.xml.

The COINS Navigator has functionality to export of import COINS Containers. Besides an increasing number of software applications are equipped with import and/or export facilities. Importing a COINS Container in the COINS Navigator is described in section 3.4.

Exporting a COINS Container

Figure 44: The File/Export menu item triggers the generation of a COINS Container.
Figure 44: The File/Export menu item triggers the generation of a COINS Container.
The File/Export menu item triggers the generation of a COINS Container. A file chooser will support the specification of the name and folder to place the container. The extension .CCR is advised to use as file type for easy filtering and selecting of containers.

The container will include the current CBIM and all referenced documents (if available on the local file system).

The COINS Navigator in its role as Building Information System is able to select a modelling area of the total BIM to be exported to a COINS Container. This option is coupled to the specification of a Window of Authorization and described in that section.

Version management

Introduction

Although many database systems support version management in one way or another, there are good reasons to store version management data also in the information model itself. In this way one standard way of representing the history of the model can be preserved over various database implementations. Conservation of the history of model modifications is also core business for building information modeling. It is simply of utmost importance to keep track of which modifications were when introduced by whom operating in which role. Apart from that, the native version management functions of the applied database system can still (and therefore should be) used for daily operation and where the COINS Building Information System (CBIS) version management data is handled in the same way as the actual content data.

Version numbering

Figure 45: Version numbers are presented as integer numbers between parentheses after the User ID/Name of the CBIM object.
Figure 45: Version numbers are presented as integer numbers between parentheses after the User ID/Name of the CBIM object.
A newly created CBIM object is automatically assigned the version number 0. At various places in the COINS Navigator user interface this version number is presented as part of the following identification sequence:
  • [ User ID ]
    The code string (presented between brackets) that can be freely assigned to a CBIM object. If no user ID is available this part will be skipped.
  • Name
    The name assigned to a CBIM object. Name should not be confused with the object ID. A CBIM ID is a globally unique URL and is not shown by the COINS Navigator.
  • ( version number )
    An integer version number (presented between parentheses) initialized with 0.

Declaring an object expired

Figure 46: An expired CBIM object is flagged in a check box.
Figure 46: An expired CBIM object is flagged in a check box.
In the COINS Building Information Model an object is never physically deleted. If an object should no longer be part of the current BIM its version is declared expired. This can be done manually by clicking the Expired check box on the identification panel.

Expired objects are closed for any changes which is expressed in the COINS Navigator by disabling the editing options of all user interface widgets. However, the expiration flag can be undone, which results in the re-admittance of this object in the current BIM. The undo option is only available as long as no next version was created. If this is the case this next version should be deleted first which is in conflict with the general concept that in CBIS an object is never deleted. Consequently this function should be used only to repair the central BIM if some information flaw is detected.

Mark: declaring an object expired is CBIS functionality under control of the BIM manager. Contributors working on an extracted CBIM imported from a COINS Container simply delete a CBIM object (of course if allowed by the window of authorization). If the result is merged with the central BIM the appropriate expiration handling is done automatically.

Creating a new version

Figure 47: Create next version message dialogue.
Figure 47: Create next version message dialogue.
After declaring an object version expired the Next version button will be enabled. Clicking this button will normally move on to the following object version. In this case there is no next version available yet and the user is asked if such a version should be created. If the user affirms this a new version will be created linked through the nextVersion attribute of the previous version.

Mark: creating a new object version is CBIS functionality under control of the BIM manager. Contributors working an an extracted CBIM imported from a COINS Container simply update existing CBIM objects (of course if allowed by the window of authorization). If the result is merged with the central BIM changed objects automatically lead to the expiration of the current versions and the creation of new object versions with the updated values.

Window of Authorization (WoA)

An important aspect of the COINS information transaction process using COINS Containers is the control over the data access rights of the person who executes an assignment. A BIM contributor typically needs access to a subset of the central BIM and will generally add, update or delete information objects to this sub-model. It should be completely unambiguous if a certain information object is accessible (read access) or can be updated (write access).

The Window of Authorization is able to specify the access status for all information objects of the central CBIM in a very compact way. The main principle is to mark certain nodes of the object tree with explicit access rights (write access, read access or no access) and to propagate these access rights along the tree branches and along the information objects that can be reached from there.

The Window of Authorization specification forms no part of the CBIM itself. A central BIM may have many parallel WoA's in several concurrent transactions. A WoA is therefore saved in a separate XML file and shipped in a separate folder of the COINS Container.

WoA Specification

Figure 48: Window of Authorization pop-up menu.
Figure 48: Window of Authorization pop-up menu.
A Window of Authorization can be specified using the object tree panel. Selecting a function fulfiller and right clicking shows a pop-up menu including a Window of Authorization sub-menu. The menu-items trigger the following functions:
  • Add write access
    Declare this object a read/write access root.
  • Add read access
    Declare this object a read-only access root.
  • Add no access
    Declare this object inaccessible.
  • Link access
    Sub-menu to fine-grain the link accessibility.
  • Remove access
    Remove the access specification.
  • Increase layer depth
    Increase the number of downward layers this access specification can reach. Initially the number of layers is set to 0 meaning: the same layer as the function fulfiller itself.
  • Decrease layer depth
    Inverse function of increase layer depth.
  • Read WoA
    Import a WoA description file.
  • Write WoA
    Export a WoA description file.
  • Propagate WoA
    Propagate the WoA root object specifications over all the information objects of the BIM.
  • Reset WoA
    Remove the current WoA specification.

Colour coding

Figure 49: Example colour coding in the object tree panel.
Figure 49: Example colour coding in the object tree panel.
To have a quick clue about the access status of a certain information object the COINS Navigator uses colour coding:
  • Green
    Full read/write access.
  • Turquoise
    Limited read/write access for certain link types.
  • Blue
    Full read-only access.
  • Violet
    Limited read access for certain link types.
  • Red
    No access.

The red colour code (no access rights) can only be observed in a CBIS environment. During the generation of a COINS Container the no-access information objects are simply skipped.

WoA violation messages

Figure 50: Window of Authorization violation warning.
Figure 50: Window of Authorization violation warning.
The COINS Navigator actively checks all changes to a CBIM object. If a violation is detected a warning message is issued.

The COINS Navigator offers the option to ignore the WoA specification. The reason is that during the execution of the assignment it may turn out that the WoA was defined to restrictively. In that case it could be very cumbersome to generate a new COINS Container and restart the transaction. Then it could be handy to circumvent the authorization. Still there is a final check during the merge operation with the central BIM. At that point in the transaction this violation will be detected and must be approved or rejected.

Object libraries

Introduction

External object libraries

Cheobs

Figure 51: Cheobs browser window.
Figure 51: Cheobs browser window.

IFD Library

Figure 52: IFD browser window.
Figure 52: IFD browser window.

ETIM

Figure 53: Etim browser window.
Figure 53: Etim browser window.

COINS libraries

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