Uniclass 2015 based dataset for ABD

Hi Brendan,

Uniclass 2015 is still evolving. I hope that Bentley is not only going to provide some 'to-be-completed-by-the-user' xsd defintions to the GB datset and leave it at that. If Bentley are serious about supporting BIM in general and Uniclass in particular, then there should also be some tools and workflows to enable:

1. Bulk updating in future. The schemas and tables are sure to change and evolve.

• The DG Explorer would need to be able to (back)update the definition .xsd(s) and the selected objects/elements in the active as well as the attached references. Even if they don't, projects evolve and schemas need to be updated and extended on a regular basis... by both users and admins.
• Bulk editing will also be needed to support collaborative working. On large projects, the spec writer is often an external consultant or a specific team member who will need to be able to modify and attach his 'data' to the model. Better he/she has the tools to do this directly in an efficient way instead of relying solely on the more error-prone way of using markups.

2. Transforming and merging objects/elements that are imported or simply copied thru from a Ref file. Sure, a lot will be defined at 'project' or 'company' level before a project starts, but inevitably a lot will need to be added as the model develops. I suspect that a lot of users will be adding to the Catalogs by importing objects either by downloading IFC objects or using the RFA Interpreter (maybe we need an IFC-I as well?) or simply copying objects/elements through from a Ref attachment. The embeded IFC, Uniclass, NRM etc information will need to be added into the project schema. i-model Transfomer-type rules-based help would be good. See also what AC provides. Maybe the Aecosim dataset team should use D++ to manage and update datasets in a smart KBE-like fashion. As mentioned above Uniclass and IFC etc are moving targets.

There should be a way to embed the object's xsd information in the object on export / import. Aecosim should be able to re-create the xsd's for any object that is imported.

3. Tools to help the user better visualise and filter the tree structure of the Uniclass (and IFC) schema.

• Please make it absolutely clear where which tree is saved.
• Will the IFC/Classification tree going to saved as system, company, project, user etc like the Datagroup System? Concatenation? Will duplicates be allowed like DGS currently is?
• I think that IFC and COBie are handled as dataset extensions via IFC_Project config. I suppose Uniclass and NRM will be handled in the same way. There should be some way to make this clear to the user; and what level of Uniclass etc is being used. Don't forget that there will be need for progressive refinement. The majority of projects will start with a reduced number of attributes / properties and very likely no or incomplete classification system.
• The user would start a roof using the Elements/Functions coding EF_30_10 which may morph into Systems Ss_25_60_50_03 'Aluminium sheet weathering systems' that will comprise all kinds elements that need product level codes like Pr_20_85_09_72 'Roof gutter brackets' etc etc. There needs to some mechanism to derive and generate the follow on codes, intelligently. Rules-based filtering of look up tables?
• Will F+P be used to carry classification info? I guess it will be; but it would be good to make this clear to user where the property is stored. Tooltip?
• Aecosim relies on mapping the DG Catalog Type to the IFC Class Type. A lot of this is only clear when the IFC is exported. It would be good to provide some smart rule-based checks for the mapping process.
• Aecosim properties = IFC attributes/properties = Uniclass properties = NRM properties. A lot of the properties will be shared/mapped. I think that there should be an option to have a multi-pane view that shows the cross schema properties side by side for clarity.

4. Tools to allow the properties and attributes to be cascaded / inherited / derived / managed from over-arching classes.

• IFC Properties have shared as well as 'private' or 'instance' properties that the user would input. The user should not be allowed to manually input these instance properties manually when there is the possibility to define this as part of a central/shared look-up table.
• The look-up table should have a means to check the 'terminology'. The user should not be allowed to guess. Dictionary?
• What about cross checking across classification and IFC schemas? Rules again?

5. The tools need to be able to deal with nested object/elements.

• The DG Explorer etc currently does not recognise objects/elements that are in an orphaned cell (Ctrl-G). The user will need to be able to schdule all element / objects as if there were un-nested.
• There needs to a way to build in IFC containment and assignment rules into the coding workflow?

6. Looking at the Uniclass table links, the Uniclass code comprises Group-Sub group-Section-Object numbers as well as a Title. As a minimum, Aecosim should be able to read these tables and provide drop-down lists, and highlight any inconsistencies. Please do not leave this to the user or CAD admin guy to fill in manually.

7. Uniclass is planned to replace CAWS for specifications and it will be key to be able to cross-check or generate spec clauses from the Uniclass data inputed into the model. The Uniclass data will also have a role for quantity take offs.

Some of the competition has been quite bullish about providing tools to help support the 'I' in BIM. What I think is emerging is a realisation that this needs to be provided in terms of IFC and other industry classification schemas like Uniclass, not just random or vendor-specific parametrics-based info. I think that AC will only get more sophisticated now that Solibri is now in the fold. Aecosim has a lot of fundamental advantages over AC: direct referencing of diverse formats like DWG, IFC, pointclouds, meshes, JT etc, federated from the start, RFA-I, Hypermodeling fusion of 2d into 3d info, ISM, i-models, Project/Asset-wise, EADOC etc etc which makes it a better platform for aggregating and manipulating BIM data from multiple sources. Plenty of muscle in on the geometry side of things. It would be good to bulk up on the non-graphic, data-centric side of things. Aecosim's historical 'soft typing' and 'everything to-be-managed-manually-by-the-user-manually' bias to non-graphic data is no longer good enough.

I am going to make suggestions a little more basic.  But I think foundational.

Create Each assembly ( as that is what a uniclass wall is) with:

1. Every part so that I can detail a section at 1/2" or larger.
2. Provide an overall part that is the uniformat part also so that I can detial a plan or section smaller than 1/2".  (for overall hatched or patterened sections)
3. Now I can do every kind of section at the detail needed relative to scale
4. Be able to annotate by part or unipart definition  as that is something we can't do now.
5. Provide a full Part library for complete scalable work  (I have a set complete if you want to talk htis over off line)
6. Provide the Full Uniformat as I am tired of creating everything beyond the minimal incomplete set provided.
7. Make sure the print well as current examples don't.  
8. Don't use Pen tables to correct poor part definitions
9. Provide a like for parts or Uniformat Assemblies to a database.    Updated once a year or yearly subscription from Means. I'd like to easily get a ROM.
10. Make sure all parts render properly and that a full list of coordinated materials are provided (ALL ALSO AT THE SAME SCALE so we use a scale of 1:1 to start and tweak only when we want something like brick to be 20x's bigger than normal.
11. Have a utility to create wall types from a model.  Updatable with a single click.
12. Make sure you are going beyond walls and include a full set of door types and assemblies.  A a true set of typical types.
13. Ditto for Windows, Bath fixtures, signage, etc.
14. Make sure you have:
    1. A singular representative wall, assembly, part, or cell for each part or assembly needed.
    2. Start with a Master, Sub and exact of each.  For example:
       1. A Level 04 00 00  Part that can be used for all Div 4 design
       2. Then if you want more control for pricing or modeling a part for each sub div.  04 10 00, 04 20 00, etc
       3. Then if you want a real estimate and a nicely rendered model go down to the final 04 10 12.2, 04 10 12.a, etc.
    3. Make sure you have a library with at least one catalog item for each and every library needed for a typical job.
       1. This way it will be easier to copy one and recreate one in that library
15. MAKE CATALOGS EASIER.
    1. To make a new one I give it a name and maybe select a type - NO MORE PROGRAMING.
    2. Make it as easy as creating a cell. - Draw it - name it - give library name and it is done and ready to use.
16. NOTE that a complicated plan may have 20 different wall types.  LINESTYLES need to be improved.

MY ASSUMPTION.  I should be able to create most buildings without editing any section.  All I should have to do is dimension and annotate Drawing View.  No hatching, patterning, flashing, "X"ing, NOTHING but annotation and Dimension.

This is beyond JUST uniformat, but without a big picture we end up with incomplete pieces.  Take Framebuilding, PCS, CCells and what do you have?  3 incomplete products and a poor representation of a door or window library.

Dominic and Eric,

thanks you for your lengthy replies. I will need to pass most of these onto the developers for future consideration as they involve changes to the application before they can be implemented in any dataset.

I do however need to draw Everyone back to the original question. Given the nature of the Uniclass 2015 system what are everyone thoughts about the organisational structure of the Level system we need to create. After all the 1192 standards required in the UK., specifies levels named in the format

Discipline_classification_presentation-Description

Do we try to use a single table?
Do we need to use multiple tables?
Will we use different tables during different phases of design e.g.( elements mainly during conceptual design being superseded by systems thereafter)

Brenden