The Limits of "One-Size-Fits-All" BIM 

While the architectural model serves as the visual container for the project, the rigorous engineering required for a remote, high-performance Eco-Village demands tools that go beyond generic geometry. A common pitfall in standard BIM workflows is the attempt to force all disciplines into a single software platform (a "closed BIM" approach), which often results in simplified structural details or schematic-only MEP systems.

The Strategy: "Best-of-Breed" Authoring 

To overcome these limitations, this research adopts a "Best-of-Breed" OpenBIM strategy. Instead of relying on a single monolith, the workflow deploys specialized vertical software suites designed explicitly for their respective engineering domains.

• For Structure: Moving beyond basic massing to fabrication-ready joinery and reinforcement.

• For MEP: Moving beyond simple 3D lines to calculated flow rates, pressure drops, and collision-free routing.

This chapter details the technical development of these two critical systems, demonstrating how distinct specialist tools—Allplan Engineering for structure and DDScad for systems—can be federated back into a cohesive whole without data loss.

Objective: To transition from architectural massing to constructible engineering systems, utilizing specialized authoring tools for Structure and MEP, and establishing the protocol for federating these disparate models into a central coordination hub.

5.1 Structural Engineering & Detailing

The integration of Building Information Modeling (BIM) within the timber construction sector has faced notable challenges, a phenomenon meticulously documented by Lobos Calquin in "Implementation of Building Information Modeling Technologies in Wood Construction: A Review of the State of the Art from a Multidisciplinary Approach." (2024). They point out that the adoption rate of BIM in projects utilizing wood as the primary material has, historically, lagged significantly when compared to its pervasive use in steel and concrete construction. This disparity is primarily attributed to historical limitations within commercially available BIM software, which often lacked the necessary specialized tools and parametric intelligence to efficiently model and manage the intricate details inherent in complex timber framing and mass timber assemblies.

The aesthetic requirement for exposed timber structure turns the structural model into a high-finish architectural element. Allplan Engineering is chosen for this task because of its superior capabilities in reinforced concrete detailing (for the complex stepped foundations) and its ability to export high-fidelity timber data for CNC fabrication (DfMA - Design for Manufacture and Assembly).

DfMA & Precision Timber Focus: Developing a "Design for Manufacture and Assembly" (DfMA) workflow for the prefabricated Japanese timber frame and modeling complex reinforced concrete foundations for steep terrain.

The Challenge of Simplicity 

While the residential scale suggests simplicity, the "Japandi" design philosophy requires the structural skeleton to remain exposed as an aesthetic element. This demands a shift from standard structural modeling to high-fidelity "cosmetic engineering." Furthermore, the "Eco-Village" mandate dictates a reduction in on-site waste. Therefore, the structural workflow is designed around off-site pre-fabrication. The BIM data must drive the CNC machines that cut the timber joinery, ensuring that the assembly on the remote site is seamless. Exposed Structure: In Japandi style, the structure (columns/beams) is often visible (exposed). This means the BIM model must be LOD 400 (Fabrication Level) because we can't hide messy joints behind drywall.

Tools:

• Authoring & Detailing: Allplan Engineering (Nemetschek) – Selected for superior reinforcement detailing and timber framing capabilities

Process:

• 1. The "Ken" Grid Coordination
  The architectural layout is strictly governed by the Japanese "Ken" module “1,82m x 1.82m”. The structural grid in Allplan is locked to this module to ensure standard lumber lengths are utilized, minimizing material waste (Eco-Goal).

• 2. Foundation Adaptation (Allplan)
  Unlike flat-site construction, the steep topography requires specialized "stepped" foundations. Allplan is utilized to model the complex geometry of the reinforced concrete grade beams that "bite" into the slope.

  • Detailing: Automated generation of rebar schedules and bending shapes for the concrete contractor, ensuring precise material ordering.

• 3. Timber Frame & Joinery (The Japandi Structure)
  The superstructure is modeled as a "Post-and-Beam" system (Zairai-jiku-gumi). Since the beams are visible, the connection nodes are not generic.

  • Action: Modeling the primary glulam (glued laminated timber) or solid timber members with precise connection points.

  • DfMA Output: The model is prepared not just for drawings, but to generate the cutting lists for off-site fabrication.

• 4. Constructability Analysis (Digital Pre-Assembly)
  Instead of relying on on-site trial and error, Allplan is used to perform a "Digital Dry Run." The software analyzes the complex nodes where steel rebar from the foundation meets the timber anchor bolts of the columns.

  • Verification: Checking for physical collisions between reinforcement bars and timber joinery to guarantee that the prefabricated kit-of-parts can be assembled on the remote site without modification.

Data Output:

• Fabrication Model [.ifc]: High-LOD geometry for timber fabricators

• Rebar Bending Schedule [.pdf/xls]: For the concrete foundation team

• Component Cutting Lists [.xls]: Precise dimensional data for every timber beam

5.2 MEP Systems Design (Mechanical, Electrical, Plumbing)

The "Invisible Engineering" Dilemma 

The core design dilemma within a Japandi cottage project is the concept of "Invisible Engineering." In conventional settings, MEP systems are conveniently concealed within suspended ceilings. However, the essence of Japandi design (Chapter 1), coupled with the celebration of the Exposed Timber Structure (Chapter 5.1), ruthlessly eliminates these traditional hiding spots. The structural timbers—the roof rafters and ceiling beams—become the finished surface, offering no forgiveness for bulky mechanical components.

Therefore, the planning of the heating and ventilation systems transforms from a standard coordination task into a game of extreme spatial precision. The MEP design cannot be merely "hidden" in a plenum; it must be meticulously integrated into the only available voids: the floor cassette and the internal partition walls.

Routing Strategy: Preserving the Ceiling 

To maintain the pristine, uncluttered aesthetic of the exposed timber roof, the routing strategy is inverted.

• Heating: Relegated entirely to the floor screed (Underfloor Heating).

• Ventilation: Instead of running ducts in the exposed ceiling, DDScad is used to route MVHR ducts through the deep Floor Void (the space between the foundation and the subfloor) or within the dropped ceiling of the central Service Core (Bathrooms/Utility). This ensures the main living spaces remain free of overhead clutter.

Focus: Developing calculation-based systems for heating, ventilation, and water, ensuring technical performance in a severe climate while respecting the minimalist aesthetic.

Tools:

• Authoring & Calculation: Graphisoft DDScad – Selected for its ability to perform physics calculations (pressure loss, heat loads) directly within the modeling environment, avoiding the need for external calculation plugins.

Process:

1. Geometric Federation (The Constraint) The workflow is initiated by importing the IFC files from Architecture (Revit) and Structure (Allplan). This establishes the "hard limits." In DDScad, I identify the specific "Service Zones"—specifically the raised floor cassette and the stud walls—where all runs must be contained.

2. Thermal Physics & Heat Load (The Calculation) Before routing a single pipe, the climatic parameters for the region (winter design temperature: -24°C) are defined. DDScad calculates the U-values of the building envelope.

• Computation: The software automatically calculates the required loop density and water flow rates to counter the significant heat loss through the large glazing.

• Strategy: To avoid unsightly radiators cluttering the minimalist interior, a Low-Temperature Underfloor Heating (UFH) system is specified. This is routed in the screed, completely invisible to the occupant.

3. Active Systems Modeling (The Solution)

• Heating (Hydronic): I model the UFH loops directly in the floor screed layer. The software validates that the loop lengths do not exceed the pressure capabilities of the central manifold.

• Ventilation (MVHR): To maintain "Eco-Village" Passive House standards, the cottages require airtight mechanical ventilation. I model a Mechanical Ventilation with Heat Recovery (MVHR) unit.

  • Physics Check: DDScad performs real-time pressure loss calculations. Because the ducts are constrained to tight floor voids or narrow wall cavities, smaller diameter ducts are often required. This physically increases air velocity and pressure resistance. The software mathematically validates that the fan unit can overcome this increased static pressure to deliver the required airflow rates (L/s) without creating noise issues.

• Electrical: Power and data cables are routed strictly within the timber stud walls. DDScad generates the automatic schematic diagrams for the switchboard panel.

4. Technical Validation (Logic Check) Unlike visual clash detection (performed in Solibri), this stage is for System Logic. DDScad verifies "Connection Logic"—ensuring that every sink is physically connected to a drain and every light switch is wired to a circuit. This prevents "orphan" elements that look correct in 3D but would fail to operate in reality.

Data Output:

• MEP Systems Model [.ifc]: Classified as IFC4 Design Transfer View.

• Hydraulic Calculation Report [.pdf]: Proof of heating performance and pressure balancing.

• Wiring Schematics [.dwg]: Generated automatically from the 3D model for the electrical contractor.

5.3 Federated Model Integration Strategy (The "Empty Container" Workflow)

The Strategic Imperative: Overcoming Digital Fragmentation 

The delivery of a high-performance Eco-Village requires a shift away from monolithic, "closed-BIM" workflows where a single software platform attempts to perform every task. Instead, this project embraces a decentralized "Best-of-Breed" philosophy, allowing structural and systems engineers to utilize the tools most optimized for their specific physics-based calculations. However, this decentralized approach introduces a critical risk: Data Fragmentation.

In a multi-platform environment, the project data is inherently siloed. Without a rigorous integration strategy, the "Digital Twin" degrades into a collection of disjointed geometric files that lack spatial coordination. Consequently, a strict OpenBIM approach—mandating the use of the vendor-neutral Industry Foundation Classes (IFC) standard—is not merely preferential but operational critical. This standardized workflow serves as the "connective tissue" of the project, establishing a Single Source of Truth (SSOT). This SSOT mechanism prevents the geometric conflicts and version control errors that typically plague projects with diverse software ecosystems, ensuring that despite the disparity in authoring tools, the construction documentation remains coherent, synchronized, and legally robust.

Focus: The technical workflow of assembling the "Federated Model," specifically defining how models authored in non-Autodesk software are aggregated back into the central Revit environment for final documentation and analysis.

The Challenge: Vendor Neutrality vs. Compatibility 

Digital construction projects often fail due to software "tribalism." This project deliberately utilizes "Best in Class" software from three competing vendors: Autodesk Revit for Architecture, Allplan Engineering for Structure, and Graphisoft DDScad for MEP. Because these platforms utilize proprietary native file formats (.rvt, .prj, .proj) that cannot natively communicate, a direct "live link" is technically impossible. Without a bridge, this leads to information silos where the architect cannot see the pipes, and the engineer cannot see the walls.

The Solution: The "Federated Container" 

To unify these disparate dialects, the "Empty Container" strategy is implemented. This involves creating a designated Revit project file that serves exclusively as the central federation hub.

• Crucial Distinction: This Container is intentionally kept devoid of any native geometry. It acts solely as a "Ghost Host," containing only the shared coordinate system and grid lines. Its singular function is to host the linked IFC models from every discipline.

• Why Revit? While Navisworks is used for clash analysis (see Chapter 6), the Revit Container is required for documentation. It allows the disparate models to be sliced into Plans, Sections, and Elevations for the creation of legal construction drawings.

The Process (The Protocol):

1. Coordinate Synchronization (The Handshake) Before any geometry is exchanged, the Shared Coordinate System (established in Chapter 2 via the Survey Point) is strictly verified to ensure spatial alignment.

• Action: A "Space Holder" IFC is exported from the Revit Container, containing only the Grid Lines and Survey Point.

• Result: The Structural (Allplan) and MEP (DDScad) teams import this file first to align their internal origins (0,0,0) to the project's real-world coordinates. This guarantees that when their models return to the federation, they snap to the correct location automatically without manual adjustment.

2. Discipline Linking (The Round-Trip) The Architectural model, Structural model, and MEP model are all exported to IFC4 Reference View.

• Action: These IFCs are "Linked" (not imported) into the empty Revit Container. Unlike a standard "Import" (which creates heavy, dead geometry), "Linking" maintains a live connection to the source file.

• Update Cycle: When the Structural Engineer updates the Allplan file, the Revit Container is updated simply by reloading the link, ensuring the documentation always reflects the latest engineering data.

3. Visibility Management (View Templates) Managing the visual chaos of overlapping models requires strict View Template management within the Container.

• Worksets: Each linked IFC is assigned to a specific Workset (e.g., LINK_Arch, LINK_Structure, LINK_MEP).

• Overrides: View Templates are configured to prioritize engineering fidelity. For example, the architectural "generic floor slabs" are hidden, revealing the detailed "hollow-core planks" from the Allplan link in their place. This ensures that coordination views always reflect the most accurate fabrication data.

Data Output:

• The Federated Project Model [.rvt]: A lightweight host file containing live links to external .ifc databases, ready for drawing production.

• IFC Mapping Table [.txt]: A configuration file ensuring that classes (e.g., "Allplan Concrete") translate correctly to Revit categories during the link process.