Federated Decentralised CDE

“STEP AP 242”:
I have to “STEP” deeper into STEP AP 242 to better understand its promises and limitations if applied to the construction sector. I like the idea to harmonize with deliberate and established STEP APs.

“decoupling”:
Decoupling of fine-grained information pieces (i.e. simple statements about facts, rules, constraints, assumptions, …) allows for computer aided evolutionary design (CAED) starting with vague ideas, schedule and budget constraints and resulting in the final real-world building.
The information pieces are collected in distributed knowledge bases.
We need algorithms

  • for consistency check between all the statements coming from several stake-holders
  • for inference from satements to proposals for design, schedule (progress over time), budget consumption (cost over time)

“different modeling paradigms”:
Need for consistency check and inference.
If algorithmic inference is possible then infer the profession specific modell (e.g. for stability calculation and simulation) from a consolidated civil engineers model.
Civil engineers model has to (almost) consistent to the architects model (i.e. architects artwork). Algorithmic consitency check between this models can be done contionously (on model change events) in the background. This is similar to spell check with improvement proposals that we know from text editors and software IDEs.

Additonally within one profession domain (architect, civil engineer, structural engineer, …) I claim a better alignment, a common modelling practice, i.e. more unification based on standardized decision rules.
In architecture for a simple “standard-case” wall (covering most use-cases) there should be ONE and only ONE standardized way to model it (modelling paradigm). For special cases I claim that the building domain expert has the freedom of decision case by case instead of presumption by software vendors preference.
Similar I claim standardization for “standard-cases” and decision freedom on building domain experts for special cases for all other professions (civil engineers, structural engineers, E, HVAC, …)

1 Like

@gester
We are in need for additional standards covering modelling practices. Standardized decision rules for modelling paradigms.
This shall be compatible and aligned to IFC and other existing standards.
IFC meanwhile provides a lot of different possibilities to describe the same factual model.
I claim a standardized way of modelling everyday standard situations, only specifically for each profession (i.e. stakeholder group) if really necessary and consensually arguable by building domain experts.

‘In architecture for a simple “standard-case” wall (covering most use-cases) there should be ONE and only ONE standardized way to model it (modelling paradigm)’

i’m curious if it can be done without losing some automation. the only right way to build models should be the way the physical building is being composed. there are systems (like ventilated facades), but mostly we still deal with parts, like in an insulated wall.

software vendors provide walls’ compounds where wall components are being gathered together for better automation and modelled together as a whole. this way i can model windows and doors with automatic component wrappings and splays, no need to do it manually. some vendors don’t offer this, and the components have to be adjusted manually in the window and door areas. for the ‘compound’ solution in the software model the insulation layer is usually cut under 45 degrees in the corners, no matter if concave or convex, which is not the way the physical insulation is being set up. so the model doesn’t help to calculate the geometry of this component rightly.

the flip side is the easiness of the model work (archicad, vectorworks), and that’s why i doubt blender (from another thread) might be that fast in creating models in a ‘compounds’ world.

i doubt if it should be done for the next levels of bim (like #3 with editable models in an open format in a cloud or sth similar, and #4).

architects and structural engineers model their parts differently, but the federated model should be buildable. for the raw structure they are only buildable using the structural models, not architectural ones, which can’t contribute to the federation or even less to the common model from the 3rd level of bim.

and this is surely true. the basis imho should be the physical building in a state of extended automation.

I think the ideas I follow not only will solve many considerations also will bring new era in the industry

  1. Materials that are BIM-ready and globally registered once and can be used multiple times
  2. Objects that are BIM-ready and globally registered once and can be used multiple times
  3. Products that are BIM-ready and globally registered once and can be used multiple times
  4. Facilities that are Smart Cities-ready and globally registered once and can be used multiple times

This is the idea behind the MaterialPass, ProductPass, and FacilityPass, BIM-ready and Smart Cities-ready content that can be assembled like LEGOs and speed up the design over 100X

if it’s not automated (many parts modelled together) it won’t speed up anything…

The’re are some POCs and even some startups that prof this concepts (and claim 100X which is acceptable, like this one: https://procedural.design)

And I agree, this is why I constantly mention “I’m working on a new Design System”

The idea I suggested is far ahead of some content-based solutions like BIMobject

This brings a new era

and what timeframe we’re talkin’ 'bout?

and yes, this is the automation principle i’ve had in mind :slight_smile: which app is the target creator? blenderbim?

…and the mentioned layers in the video should be the construction classification system’s hierarchic classes.

The Design System I have in mind is advanced than the presentation I shared, and layer design and procedural design is just about 20% of it

MaterialPass, ProductPass and FacilityPass projects are open source, so it’s up to all of us. The time frame could be anytime (because it’s open source)

BlenderBIM opened the door and even we shared a POC:

I’m not sure about the platform, Blender and BlenderBIM still have limitations for the idea I have in mind for “Assembly Modeling” part, and I don’t think about a platform like FreeCAD

@gester
“… the way the phyiscal building is being composed …”
In early design phase we do not know the way the physical building will be composed later.
In tender phase we often MUST NOT restrict the way the of implementation.
In tender phase we specify the wall as abstract building element with some requirements that can be implemented in different ways by the (sub-)contractor.

a) If implemented as site concrete we extrude the liquid concrete from bottom to top => vertical extrusion?
We later apply the isolation from outside and/or inside. => NO vertical extrusion !
b) If implemented as precast we extrude the liquid concrete from inside to outside and deliver the cured concrete part it to the site where it is mounted to the building. => horizontal extrusion?
Isolation can be applied at factory or at site from inside and/or outside. => how to model ?
c) If implemented as hollow wall we build a hollow room bounded by plasterboard plate => Brep ?

In tender phase we are neutral to contractors and specific implementation. We need ONE standardized way to describe the requirements for “the wall”.
We need algorithms to check for the equivalence of requirements (tender offer) and implementation (bids).

@gester
“… modelled together as a whole…”
Concrete and insulation are dividable in real life and therefore shall be divided in the model. Concrete and insulation are built at different time and therefore shall be divided in the modell.
Automation shall be done at model manipulation level (access methods operating on the model data).

well, i don’t mean if a wall is of in-situ reinforced concrete or as a precast, or even a ceramic brick but how the main components are being assembled. we surely know that interior walls come first, and the flooring layers next.
it doesn’t have anything to do with the project phase, but it has everything to do with the lod levels, and the appropriate classification level.

but surely the flexibility is an issue, too.

this is the question of easiness of modelling and automation vs the design sincerity and flexibility we’re talking about here…

…but such concepts as the viennese procedural design might be a remedium for.

Easiness of modelling and automation shall NOT be provided by oversimplified model conceptions.

Easiness of modelling and automation shall be provided by microservices that operate on the model by means of basic operations (i.e. methods, functions, procedures, … however you like to call it …).

Model conceptions shall be appropriate to help solving the considered problems . This can be interpreted extensively.
Misguided by the assumption that simple model conceptions simplify the considered problems we typically end up with oversimplified model conceptions that are inadequate for effective problem solving.
The basis for model conception should be the physical building (in very detail and close to reality) instead of easiness and automation. The microservices will provide easy, user-friendly automation to hide the model complexity from the users (architects, structural engineers, …), especially for common planning steps.

nobody said this :slight_smile: that’s why we look here for solutions

this was my standpoint, too :wink:

I think anything you mention would happen in the project I do

High level of detail (LoD) model based on the right geometry paradigm(s) that modeled once and accepted globally, and can have some geometry representations too which represent the main geometry (AP 422 has something like this I think) inside the Material/Object/Product Passport and are natural in different worlds GIS, BIM, PLM, VFX, XR, … and appropriate data/information/knowledge can be linked to these materials and geometries based on use-cases

is it supposed to be a plugin for existing cad/bim applications, or a standalone product?

I disclaim modelling together as a whole what is not a whole in accordance with empirical realism.
I disclaim modelling practices in discrepancy to reality that make life easier for software developers at the cost of having models that are not in accordance with empirical realism.

Modelling of windows and doors with automatic component wrappings and splays is the duty of the microservices that are operating on the realistic model. The model itself shall be based on a precise model conception that are consistent with empirical realism.

Summarized:
I welcome operations for automatic component wrappings and splays.
I refuse model conception that imposes compounds that are in contrast to empirical realism (e.g. for facultative insulation that is mounted to a concrete wall at a different time period)

1 Like

I refuse software models that are inconsistent to empirical realism (e.g. in contradiction to the way the physical insulation is being set up)

Model conceptions need to abstract from reality. This can be done by omitting details or by simplified representation of details. But I refuse model conceptions that prescribe wrong details (e.g. 45 degrees insulation cut).

I welcome model conceptions that
a) omit unknownd details (e.g. the insulation cut angle)
or
b) request user specification of detail (e.g. the insulation cut angle)
or
c) use common detail as default (e.g. a common insulation cut angle) and allow for user intervention to deviate from default