Uniclass 2015 based dataset for ABD

We, Bentley, have been working on compiling an ABD dataset compatible with Uniclass 2015 for some time. The recent changes to the tables has provided an opportunity to carry out a sanity check and ask you users of ABD etc. for your opinion about this standard and how you would want to see it implemented within ABD.

We are particularly interested in your views about how to set up a layering system, what information you would expect to see predefined in the dataset and what you would expect to set your self. Please remember we also have to consider the relevant standards for CAD levels, object naming  etc.

Here is a link to the NBS website that has information about the Uniclass Standard.

 

If possible we would like you feedback as soon as possible, including examples and reasoning.

 

Many Thanks

Brenden

Parents
  • 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

    Brenden Roche

    Applications Engineer

    Bentley Systems, Manchester UK


    This is a test

Reply
  • 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

    Brenden Roche

    Applications Engineer

    Bentley Systems, Manchester UK


    This is a test

Children
  • I guess I dont understand as each part would have a level
    Then the Uniformat would have a level by that Uniformat Category

    I'd wnat to know hte types of VIEWS I'd wnat to control levels for.

    Exterior Walls
    Interior Walls
    Roof, etc

    Ustn since 1988
    SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64b

    Eric D. Milberger
    Architect + Master Planner + BIM

    Senior  Master Planner NASA - Marshall Space Flight Center

    The Milberger Architectural Group, llc

  • Eric,

    Uniclass is the UK's version of Omniclass. Here is a 'quick' description.

  • Unknown said:
    Do we try to use a single table?

    Looking at BS 1192-4:2014 (COBie) which is unfortunately not aligned with Uniclass 2015, there is reference to Table D Facilities (Ac Activities + Co Complexes), E (En Entities), F (Sp Spaces), G+H (Ee Elements) , L ( Pr Products), C Management. So I guess the answer is 'no'. Table 7 also suggests that some of the Uniclass tables can be replaced by other NRM tables.

    Unknown said:
    Do we need to use multiple tables?

    Probably. But, the UI needs to be able to aggregate the multiple tables sensibly for the user based on the relevant schema or task. COBie is related to one task / MVD. Plenty of other MVD's.

    • Building Automation Information Exchange [BAMie]
    • Building Programming Information Exchange [BPie]
    • Facilities Management Handover [COBie]
    • Mechanical Design Information Exchange [HVACie]
    • Electrical Design Information Exchange [SPARKie]
    • Plumbing Design Information Exchange [WSie]

    Bentley would need to start using mvdXML and Ifcdoc to avoid drowning in future by supporting:

    "dynamic functionality that may be supported include:

    • Exporting data that is automatically filtered to include only data within a model view
    • Downloading data from a server (where MVDXML essentially serves as a query language)
    • Validating data to ensure it contains required information
    • Prompting users to provide missing information
    • Providing re-usable templates for product types, including parametric behaviors
    • Importing and exporting tabular data with specified configurations of tables and columns
    • Filtering application functionality to a subset within a model view (e.g. electrical domain)
    • Providing attribute editing functionality for high-level concepts instead of low-level data."

    Soft-typing vs hard typing is not really a preference question. Some properties will need to be hard-typed and managed using rules. It would seem that a lot of these rules would be defined and captured in xml format. IFC itself is written using a data definition language (Express-G). At the moment, there is a dangerous lack of tools to manage all those properties that will be needed to comply with BIM standards.

    Unknown said:
    Will we use different tables during different phases of design e.g.( elements mainly during conceptual design being superseded by systems thereafter)

    Apparently, the answer is yes according to PAS 1192-2 and COBie's take on Data Drops.

    Concept cost information NRM1, CESMM
    Detailed cost information NRM2, CESMN
    Concept design information Uniclass/Entities, Spaces, Elements tables
    Production information Uniclass/Elements, System tables
    Installation information Uniclass/Systems, Work results, Product tables
    As constructed information Uniclass/Systems, Products tables
    In-use design information Uniclass/Systems, Work results, Products tables
    Maintenance cost information NRM3

    Need to develop the tools to handle the requirements behind these questions. Just formating and populating some of the property fields by itself is a start but not the answer.

  • I understand ans was looking at the Unical/Omniclass peices and how they would be used in a model to construct the 2d documents and the model.  Not just the same and standards for that name.  Kind of liek the discussion we went through after the AIA created a dead level symbology we have today.

    I was looking at what would be your final naming and structure based upon what you need to create documents.

    I need a PIECE that is composed of parts and a summary Piece

    the parts are easy - anythgin I'd want to quantify or measure in a darwing.

    The summary piece is what carries the Uniformat/Omniformat Name and data as a whole while the parts cary part information.

    This would may be an overall part that could be created from the pieces or a manual Part with the Uniformat name.

    Maybe this is the piece you measure from or the part that defines visible surfaces.

    Thus you may need another part that is the part to measure.

    for example.  typical stud wall with brick face, conc. footing and coping.

    1. Each part is an assembly is obvious.  Though if the brick has reveals or multiple colors and depths is gets more interesting.
    2. Then you have a part that is measureable like the CMU block that is the main struacture that  everything is measured from.  This might be another part that is measurable.
    3. Then you have an overall part that holds the Uniformat specific inforatmation.

    The name would be composed from these.

    And I would use Master Format for the parts this a start on the Assembly.

    Think of how you build the model maybe as an ordering - Ground, Site, Footing, Foudation, Struture, Exterior Walls, floors, Roofs, Interior Walls Finishes, etc.

    How you build in real life is very similar to how you ahve to bulild your model and how products relate to each other in thought.

    You could still have a key to interpret the name but DO REMEMBER WE ARE NO LONGER Limited to 8 characters

    So I'd likd a medium name with abbreviated names that tell the story

    Horrible name but I would look at how I can divide this into libraries of Assemblies  As each library could have many many assemblies. 

    Wall-Int-STLstud-gyp-brick

    Ustn since 1988
    SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64b

    Eric D. Milberger
    Architect + Master Planner + BIM

    Senior  Master Planner NASA - Marshall Space Flight Center

    The Milberger Architectural Group, llc

  • Emil,

    I think that you are looking things wrong.

    IFC is about composition and spatial containment or 'part of' relationships, while Uniclass is about 'type of' relationships. If one does one kind of hierarchy, it would be good not to mix it up with another.

    Naming is context based. COBie has a particular requirement based on producing concatenated names based on various properties. It also has a requirement to number them uniquely. I suspect that the other MVD's will have other naming requirements.

    You seem to want to 'hard code' the naming/numbering system. I think that you will end up with a 'dead end' situation repeating the problem you mentioned in your post.

    What we should be looking at is providing the tools to re-map, generate, cascade names as required according to any selected Schema.