Difference between revisions of "MicroMVDs for exchange requirements"
Line 29: | Line 29: | ||
* [[Model federation MicroMVD]] | * [[Model federation MicroMVD]] | ||
* [[Element classes MicroMVD]] | * [[Element classes MicroMVD]] | ||
+ | * [[Geocoding MicroMVD]] | ||
* [[Classification MicroMVD]] | * [[Classification MicroMVD]] | ||
* [[Naming MicroMVD]] | * [[Naming MicroMVD]] |
Revision as of 04:01, 28 July 2020
To guarantee correct BIM data, data exchange requirements need to be specified and audited. A MicroMVD is a collection of sentences that describe auditing requirements, written in plain language understood by both technical and non-technical stakeholders. These sentences are organised into categories, and can be processed by a computer to automatically check whether or not the requirements are satisfied.
Here is an example of a simple MicroMVD, which checks that an IFC4 file is provided with a particular filename.
Feature: Project setup In order to view the BIM data As any interested stakeholder We need an IFC file Scenario: Receiving a file * The IFC file "project.ifc" must be provided * IFC data must use the IFC4 schema
This MicroMVD is stored in a simple text file with the .feature
file extension. The file name is arbitrary, but may be used to describe what it is auditing. These simple text files can be edited in any text editor, such as Vim, Apple TextEdit, or Microsoft Notepad. No proprietary software is required: anybody can read and write MicroMVDs.
These *.feature
files, each containing sentences like the above can be processed by a computer. In the example above, a MicroMVD auditing program will look for a file named "project.ifc
" and will check that it is IFC4
. The MicroMVD auditing program can then generate a report, which can be used by stakeholers to track whether or not a project is satisfying its requirements.
Unlike other auditing solutions like Solibri or SimpleBIM, MicroMVDs are non-proprietary, do not expire, are free, much lighter, are easy to change and develop, and are cross-platform.
List of MicroMVDs
Although you are free to write your own MicroMVD specific to your project, a series of MicroMVDs have been published online that address common problems. You can copy and paste these templates into your own *.feature
files, and modify it to suite your project.
- Project setup MicroMVD
- Geolocation MicroMVD
- Model federation MicroMVD
- Element classes MicroMVD
- Geocoding MicroMVD
- Classification MicroMVD
- Naming MicroMVD
- Material MicroMVD
- COBie MicroMVD
Auditing BIM data with MicroMVDs
You will need a MicroMVD auditing program. One free and open source option is BIMTester.
TODO: describe how to use BIMTester.
Authoring a custom MicroMVD
If you wish to write your own custom MicroMVD, some basic technical knowledge is required. The first is how to structure a MicroMVD. Each MicroMVD must follow the generic format shown below:
Feature: Name of the exchange requirement In order to achieve a business goal As a particular user or stakeholder We need to satisfy specific technical requirements Scenario: Check a particular technical requirement * Some data must be in a certain way * Some other data must be in another way Scenario: Check another particular technical requirement * Some data must be in a certain way * Some other data must be in another way
A feature file always starts by defining the name of the Feature
. Below the feature name is an three sentence paragraph which describes the value this MicroMVD delivers to the project. This paragraph is optional, but encouraged to help align both technical and non-technical project participants.
The individual audits are then categorised into one or more Scenario
blocks. Each scenario has a name that focuses on a particular technical requirement of the exchange requirement, and contains one or more test sentences. Each sentence checks data related to the scenario. The feature name and scenario names can be anything, but must be prefixed by Feature:
and Scenario:
respectively. The test sentences within each Scenario
block must match a pattern defined in the MicroMVD for the project.
These MicroMVDs are templates to be used as a starting point for projects to describe exchange requirements. It is encouraged to modify it to project requirements, delete irrelevant tests, and add new tests as required.
Packaging test suites for recipients
The author of the test suite will provide a folder named features/
. The contents of this folder will contain:
features/test-suite-A.feature # This is a test suite features/test-suite-B.feature # This is another test suite, you can have multiple features/environment.py # This defines the test environment features/template.html # This is the HTML report template features/steps/steps.py # The defines the test sentences
These files constitute the full test system, and must be shared in full to all recipients and all authors. This ensures full transparency of exchange requirements.
The steps.py
file requires basic programming knowledge to understand and modify, and is generally only modified by the test author. Recipients are free to inspect it to gain a better understanding of what constitutes test compliance.
The environment.py
file contains the environment settings to run the tests, using the Behave system. An intermediate knowledge of Behave and Python is required to modify this file. For most recipients, this file must be left alone.
The template.html
file contains a HTML report template. It is plain HTML code with Mustache for the templating language. A basic knowledge of HTML and Mustache is required to modify this file, which is self-explanatory.
Receiving and running test suites
A recipient will receive a features/
directory. They are not required to modify the files in any way.
The cross-platform, free software BIMTester tool is capable of running the test suite and generating reports. The BIMTester tool expects the features/
directory to be in the current working directory.
Recipients are encouraged to run the tests and generate reports at their convenience. The test author may optionally provide an automated platform which runs tests and generate downloadable reports, as well as track progress on test results.
Maintaining test suites
The test suite will be working document that will grow throughout the project lifecycle to ensure that data quality regressions are not made, and that the level of information which has been audited is clearly documented.
The test author will advise all recipients whenever new tests are being introduced or new test sentences are being defined.