אם כולם סביבך זורקים ראשי תיבות כמו BEP, LOD, CDE ו-IFC כאילו מדובר במילים בסיסיות - הגעתם למקום הנכון. 540 מונחים, מהיסודות ועד לכל ממדי ה-BIM, עם קישורים בין מושגים קרובים. ← מאמרים
רוצים לשים את המושגים האלה לפועל?
לקורסי Revit שלנו ←התחילו להקליד כדי לחפש מונח, או בחרו קטגוריה למעלה.
גיאומטריה
"ממדי" ה-BIM מתארים איזו שכבת מידע מתווספת על גבי המודל התלת-מימדי. תחשוב על 3D כבסיס - כל ממד נוסף מעשיר את המודל בסוג חדש של נתונים.
המודל הבסיסי. קירות, רצפות, גגות, עמודים, תעלות, צינורות - כולם מדולגים כאובייקטים תלת-מימדיים חכמים במרחב. זה מה שרוב האנשים מדמיינים כשהם שומעים "מודל Revit".
סטאק ממדי BIM (3D–10D)
בעוד ש-Enscape או Twinmotion מעדיפים מהירות ואינטראקטיביות חיה, 3ds Max הוא בדרך כלל הבחירה כשפרויקט זקוק לשליטה הנוספת ולליטוש של תמונת סטילס שמרונדרת במלואה במצב לא-מקוון.
זמן
המודל מקושר ללוח זמנים של הבנייה. כל אלמנט קשור למשימה ולתאריך, כך שניתן להנפיש את רצף הבנייה, לאתר קונפליקטים בתזמון לפני תחילת העבודה ולתקשר את תוכנית הבנייה לכל בעלי העניין בצורה ויזואלית.
עלות
המודל מקושר לנתוני עלות. כמויות מוסקות ישירות מאלמנטים מדולגים ומוכפלות בתעריפי יחידה, מה שמספק מעקב תקציבי בזמן אמת ככל שהתכנון מתפתח. שינויים במודל מעדכנים אוטומטית את האומדן.
קיימות
המודל משמש לניתוח אנרגיה וסביבה. BIM 6D מעריך רמות תאורת יום, עומסי חימום וקירור, טביעת רגל פחמנית והשפעה סביבתית לאורך מחזור החיים - כבר משלבי התכנון המוקדמים, כשהשינויים עדיין זולים לביצוע.
ניהול מתקן
המודל שנמסר למפעילי המבנה לאחר סיום הבנייה. נתוני נכסים - מפרטי ציוד, תקופות אחריות, לוחות תחזוקה, מחזורי החלפה - משובצים במודל ומשמשים את צוות ניהול המתקן לאורך חיי הפעלת המבנה.
בטיחות
מידע בטיחותי משולב במודל. BIM 8D מזהה סכנות באתר הבנייה, מדמה תרחישי סיכון ומשלב נהלי בטיחות ברצף הבנייה. הוא עוזר לקבלנים לתכנן אתרים בטוחים יותר לפני שמישהו דורך בהם.
בנייה רזה
המודל משמש לאופטימיזציה של תהליכים וצמצום בזבוז. BIM 9D מיישם עקרונות בנייה רזה - מזעור זמני השבתה, תזמון עבודה יעיל, צמצום בזבוז חומרים - ומזין את השיפורים חזרה לתוכנית הבנייה.
תיעוש ותאומים דיגיטליים
הממד המתקדם ביותר. BIM 10D משלב נתוני טרום-ייצור ובנייה מודולרית (סבילויות ייצור מחוץ לאתר, לוגיסטיקת אספקה, רצפי הרכבה) ומזין תאום דיגיטלי - העתק וירטואלי חי של המבנה שממשיך לקבל נתוני עולם אמיתי מחיישנים זמן רב לאחר סיום הבנייה.
הערה: ממדים 3D עד 7D מאומצים ומתוקננים באופן נרחב. ממדים 8D–10D בשימוש גובר אך טרם הוגדרו באופן אחיד בכל גופי התקינה.
Aconex ממלאת תפקיד דומה לצד ניהול המסמכים של Newforma או Procore - רשומה אחת, ניתנת לביקורת, של כל רוויזיית שרטוט, מסמך הגשה ואישור בפרויקט - אך זוכה לאימוץ חזק במיוחד בתשתיות בינלאומיות גדולות ומגה-פרויקטים מחוץ לצפון אמריקה.
סוג משפחה מיוחד שנקודות המיקום שלו אינן קבועות - הן מתאימות את עצמן כדי להתיישר עם מארח, כמו משטח מחולק, רשת פאנלים של קיר מסך מעוקל, או נתיב שמוגדר על ידי גרף Dynamo. במקום צורה נוקשה אחת, Adaptive Component מכופף את הגיאומטריה שלו כדי להתאים לכל מקום שבו הנקודות שלו נוחתות, וזה מה שהופך פאנלים מורכבים ולא-חוזרים בחזית או מבני חופה לאפשריים בלי מידול ידני של כל חתיכה ייחודית.
הן הטכניקה הסטנדרטית לפאנול משטח מעוקל או חופשי-צורה: הניחו משפחה אדפטיבית אחת, החילו אותה על פני משטח מחולק שלם, וכל מופע מעצב את עצמו מחדש אוטומטית כדי להתאים למיקום הפאנל הייחודי שלו.
חלק מהתוספים רצים דרך ה-Revit API ישירות ודורשים תכנות אמיתי; אחרים, כמו Dynamo, מציעים שכבה ויזואלית מעל אותו API כך שגם לא-מתכנתים יכולים להפוך משימות לאוטומטיות.
הוא קיים ספציפית כי סכסוכי בנייה לא יכולים לחכות שנים להיפתר בלי לעכב פרויקט שלם - החלטה מחייבת מיידית, גם אם כל צד עדיין יכול לערער עליה מאוחר יותר דרך בוררות דין או הליך משפטי.
שרטוטים מאושרים לביצוע
הסטטוס הסופי שאליו מגיע שרטוט לאחר שצוות התכנון, ולעיתים קרובות גם הלקוח או הרשות המאשרת, חתם עליו - העבודה יכולה להתחיל באתר באופן חוקי מהגרסה הזו. AFC הוא התחנה האחרונה במחזור החיים של סטטוס השרטוט ב-CDE (בעבודה, משותף, מפורסם/AFC), וכל שינוי אחרי השלב הזה דורש רוויזיה פורמלית, לא עריכה שקטה.
באופן מבלבל, חלק מהמשרדים משתמשים ב-AFC וב-IFC Drawings כמעט לסירוגין; אחרים מפרידים בצורה חדה יותר - IFC מסמן את הרגע שבו השרטוטים מונפקים לצוות האתר, בעוד ש-AFC מאשר שהם אושרו רשמית, מה שעשוי לקרות מוקדם או מאוחר יותר, תלוי בתהליך מעקב הבעיות של הפרויקט. בכל מקרה, ברגע שסט שרטוטים מוחלף ברוויזיית AFC חדשה יותר, יש לסמן את הישן בבירור כבטל, כדי להימנע מהטעות הקלאסית והיקרה של קבלן שבונה מגיליון מיושן.
בעוד שהרשומה הרחבה יותר "AIA Contract Documents" מכסה את כל המשפחה, A201 הוא הספציפי שרוב אנשי המקצוע בבנייה בארה"ב בפועל מתכוונים אליו כשהם פשוט אומרים "התנאים הכלליים של AIA".
מסמכי חוזה של האיגוד האמריקאי לאדריכלים
מסמכי E203/G202 של AIA שולטים באופן ספציפי בפרוטוקולי BIM ונתונים דיגיטליים בפרויקטים אמריקאיים, וממלאים תפקיד דומה ל-BEP בפרויקט לפי ISO 19650 - מגדירים בעלות על המודל, ציפיות LOD ובעלות על נתונים בתוך מסגרת החוזה הרחבה יותר של AIA.
Asset Information Model
החצי השני של הצמד. ה-AIM הוא מודל המידע שמשמש לתפעול ותחזוקת המבנה אחרי המסירה: רישום נכסים, נתוני ציוד, לוחות תחזוקה, אחריות ומודלי as-built.
אם ה-PIM עונה על "איך בונים את זה?", ה-AIM עונה על "איך מפעילים את זה?" - ו-COBie הוא אחד הכלים הנפוצים להעברת נתונים מהאחד לשני.
Asset Information Requirements
התאום התפעולי של ה-EIR. בעוד שה-EIR מגדיר איזה מידע הלקוח צריך במהלך התכנון והבנייה, ה-AIR מגדיר איזה מידע הלקוח צריך כדי לתפעל את המבנה לאחר המסירה - לוחות תחזוקה, נתוני אחריות, מדריכי ציוד, רשימות חלקי חילוף.
ה-AIR מוזן ישירות לתוך ה-AIM: הוא בעצם המפרט של מה שמודל מידע הנכס חייב להכיל. AIR כתוב היטב בתחילת הפרויקט הופך את המסירה הסופית לניהול המתקן לחלקה בהרבה, כי כולם יודעים מהיום הראשון בדיוק אילו נתונים צריך לאסוף.
נעילת יישור אחרי השימוש בו שומרת על שני האלמנטים קשורים יחד קדימה - הזזת הרפרנס מאוחר יותר, והאלמנט המיושר עוקב אחריו אוטומטית.
היא נמצאת באותה משפחת Nemetschek כמו Vectorworks, עוד נקודת מידע לכמה מפוצג שוק יצירת ה-BIM בפועל ברגע שמסתכלים מעבר לשוק דובר האנגלית הממוקד-Revit.
זוהי המקבילה למשפחת מודל: תגית דלת, ראש קומה וסמל צפון הם כולם משפחות סימון, שמתאימות את עצמן לגודל התצוגה במקום להתקיים בגודל אמיתי במרחב תלת-ממדי.
אחד התפקידים המוגדרים ב-ISO 19650: Appointing Party הוא הארגון שמזמין את העבודה - בדרך כלל הלקוח - האחראי על קביעת ה-EIR ובסופו של דבר החלטה איזה מידע הוא צריך. כל תפקיד אחר במינוח התקן מוגדר יחסית לתפקיד הזה: ה-Appointing Party ממנה Lead Appointed Party, שבתורו עשוי למנות Task Teams נוספים.
הכרת שמות התפקידים האלה חשובה בעיקר בקריאת חוזה או BEP תואמי-ISO 19650 ישירות - התקן משתמש בהם בדיוק ובעקביות, והמינוח יכול אחרת להישמע פורמלי שלא לצורך עבור מה שבשפה פשוטה הוא פשוט "הלקוח".
Approved Document B: בטיחות אש (תקנות הבנייה הבריטיות)
פרמטרי דירוג אש על משפחות קירות ודלתות ברוויט, בדיקות מרחק מילוט על נתיבי בריחה, וגבולות מדורים בתוכניות - כל אלה קיימים במיוחד כדי להוכיח עמידה ב-Approved Document B - זו אחת הסיבות הנפוצות ביותר לכך שתכנון נשלח בחזרה לתיקון בשלב מאוחר בפרויקט.
ככל שמבנים נבנים באיטום הולך וגובר כדי לעמוד ביעדי האנרגיה של Part L, דרישות האוורור של Part F הופכות למשקל הנגדי ששומר עליהם בריאים לחיות בהם בפועל.
זהו הרצפה הרגולטורית שמולה נמדדות שאיפות הפחמן התפעולי ואפס-הנטו של פרויקט - עמידה ב-Part L היא המינימום החוקי, ופרויקטים רבים כיום קובעים יעדים משלהם הרבה מעבר לכך.
היא נמצאת לצד Approved Documents B ו-L כאחת משלושת החלקים הנבדקים בתדירות הגבוהה ביותר בתקנות כמעט בכל פרויקט בנייה.
Autodesk Platform Services (formerly Forge)
חבילת ה-API-ים בענן של Autodesk - שנקראה בעבר Forge, שונה לשם Autodesk Platform Services - שמאפשרת למפתחים לבנות אפליקציות מותאמות מעל נתוני BIM בלי צורך ב-Revit מותקן: צפייה במודלים בדפדפן, אוטומציה של בדיקות מודל, שליפת נתונים בקנה מידה, או חיבור נתוני ה-BIM של פרויקט לתוכנה הפנימית של חברה.
בעוד ש-Dynamo מבצע אוטומציה בתוך סשן Revit פתוח אחד, APS פועל ברמת פלטפורמה - בצד השרת, מתארח בענן, מסוגל לעבד מודלים של פרויקטים רבים בלי אדם שיושב מול שולחן עבודה. זו השכבה שכלי BIM מותאמים-בית ומוצרי טכנולוגיית בנייה גדולים יותר בדרך כלל נבנים עליה.
בעוד שבוררות מהירה (adjudication) מהירה וזמנית, בוררות דין (arbitration) איטית יותר אך סופית - חוזי בנייה בינלאומיים רבים, כולל FIDIC, מגדירים בוררות דין כמסלול הסופי אם מנגנוני יישוב סכסוכים מוקדמים יותר נכשלים.
זהו הכלי שנמצא לרוב בצד ה-GIS של שילוב GIS-BIM, ומקבל נתוני מודל מאוחד שיוצאו או הוזרמו מהצד של Autodesk/Bentley.
היא חולקת את אותה פילוסופיית מודלינג מבוסס-אובייקטים כמו Revit אך מגיעה משושלת נפרדת לגמרי - Teamwork היא מערכת שיתוף העבודה שלה, ו-IFC הוא בדרך כלל הגשר המעשי כשאדריכל מבוסס-ArchiCAD מתאם עם מהנדס מבוסס-Revit.
בעוד ש-room-vs-space עולה בדרך כלל בהקשר של תיאום MEP, תוכניות שטחים משרתות מטרה שונה לגמרי - חישובי שטח בנוי ברוטו ושטח להשכרה עבור אישור תכנוני או השכרה, המשורטטים עם קווי גבול שטח משלהם ולא תגיות חדר.
שורה של בולרד חנייה במרווחים שווים או דפוס רדיאלי של עמודים סביב מבנה מעוקל הם סוג הפריסות החוזרות ש-Array מטפל בהן בשניות במקום להציב כל אחד ידנית.
As Built Model
המודל שמשקף את מה שנבנה בפועל - לא את מה שתוכנן. במהלך הביצוע נערכים שינויים: תוואי צנרת זז, קורה הוגבהה, קיר הוזז. מודל העדות מעדכן את כל אלה, ולעיתים מאומת מול סריקות לייזר של המבנה הגמור (Scan to BIM).
הוא הבסיס ל-AIM ולניהול המתקן - כי אי אפשר לתחזק מבנה לפי מודל שלא מספר את האמת. בישראל תשמעו גם "תוכניות עדות" - זה אותו רעיון, בעולם המודלים.
As Designed Model
הנקודה השלישית בשלישיית תכנון-לביצוע, לצד As Made ו-As Built. מודל As Designed הוא כוונת התכנון המקורית של צוות התכנון - מה שהיה אמור להיבנות, בהתבסס על החלטות התכנון שהתקבלו לפני תחילת הבנייה. הוא קו הבסיס שכל השאר נמדד מולו: As Made תופס מה שהותקן בפועל באתר, As Built הוא הרשומה המתואמת של המבנה המושלם, והפער בין As Designed ל-As Built הוא, בפועל, מפה של כל שינוי שקרה במהלך הבנייה.
שמירה על מודל ה-As Designed שלם, במקום לדרוס אותו בשינויי אתר, חשובה בדיוק מהסיבה הזו - בלעדיה, אין דרך לראות עד כמה המבנה המוגמר באמת סטה מהתוכנית המקורית.
בבנייה בשיטת DfMA ובבנייה מודולרית, אלמנטים נבנים במפעל בטולרנסים מדויקים לפני שהם מגיעים לאתר בכלל - as fabricated תופס את המצב המיוצר הזה, שאותו אפשר להשוות הן לכוונת התכנון והן, מאוחר יותר, למציאות בשטח לאחר ההתקנה, כדי לתפוס פערים מוקדם, כשעדיין זול לתקן אותם.
As Made Model
תיעוד - לרוב ברמת רכיב או חיבור - של מה שהותקן או נבנה בפועל באתר, הנאסף בדרך כלל על ידי צוות הביצוע ישירות ממדידות או סריקות באתר. נתוני As-Made הם לרוב מפורטים ומיידיים יותר ממודל As-Built: הם מופקים דיסציפלינה-דיסציפלינה תוך כדי העבודה, לפני האיחוד לתמונה אחת.
תיעוד ה-As-Made מוזן לאחר מכן למודל ה-As-Built הרחב יותר - צוות התכנון מעדכן את מודל כוונת התכנון בנתוני ה-As-Made (בתוספת אימות נוסף) כדי להפיק את הרשומה המתואמת האחת של המבנה המושלם. בקצרה: As-Made הוא האמת הגולמית מהאתר; As-Built הוא המודל המתואם שנבנה ממנה.
As-Occupied Model
הנקודה הרביעית, הפחות-נדונה בציר הזמן מתכנון לתפעול, לצד As Designed, As Made ו-As Built. מצב As Occupied תופס מבנה לאחר שדיירים ומפעילים בפועל עוברים אליו ומתחילים לשנות דברים - סידור מחדש של מחיצות, הוספת ציוד, שינוי גימורים - שינויים שקורים לגמרי מחוץ לשליטה או מודעות של צוות הפרויקט המקורי.
שמירה על רשומת As Occupied עדכנית קשה באמת, וזו בדיוק הסיבה שזה חשוב: AIM שהיה מדויק ביום המסירה נסחף בהדרגה מהמציאות ככל שדיירים עושים שינויים משלהם, וצוות ניהול מתקן שעובד ממודל מיושן מתכנן תחזוקה ושיפוצים מול מבנה שכבר לא באמת קיים בצורה הזו.
"כפי שתוכנן" (As Planned) הוא קו הבסיס שכולם נמדדים מולו - התקדמות הביצוע, חריגות בלוח הזמנים (4D BIM), וסטיות ה-as-built הסופיות - כולם נמדדים חזרה מול התוכנית המקורית הזו. הוא נמצא לצד as-designed, as-made, as-built ו-as-occupied כאחד ממונחי מצב הפרויקט המוכרים.
זהו שלב בקרת האיכות שמאחורי כל תהליך ה-scan-to-BIM וה-as-built: ענן נקודות מוצב על גבי מודל ה-as-built, וכל סטייה מעבר לסבילות מוסכמת מסומנת לפני שהמודל מאושר ונמסר.
היא נמצאת בתחילת משפחת ה-as-*, עוד לפני שas-designed בכלל מתחיל - סקר מצב מבנה או מודל scan-to-BIM הם בדרך כלל האופן שבו מצב as-existing באמת נלכד ומתומדל.
תהליך הסטטוס של CDE קיים בדיוק כדי להפריד עבודה בתהליך ממידע as-issued - רק השני בטוח שגורם אחר יסמוך עליו ויבנה ממנו בפועל.
מודל as-built קופא ברגע המסירה; רשומת as-maintained ממשיכה לזוז אחריו, ותופסת את הדוד שהוחלף בשנה השלישית או את הגג שכוסה מחדש בשנה השמינית - בדיוק מה שצוות FM צריך כדי לסמוך על ה-AIM שנים אחר כך.
בפרויקט retrofit הוא נבדק לפני שאפילו הקיר הראשון נפתח - רשומות חסרות או לא מעודכנות הן אחת הסיבות הנפוצות ביותר לעצירת עבודה בשל בטיחות בשלב הביצוע.
האגודה האמריקאית למהנדסי חימום, קירור ומיזוג אוויר
ASHRAE 90.1 (יעילות אנרגטית) ו-ASHRAE 62.1 (אוורור) הם שני התקנים שמהנדסי MEP מפנים אליהם כל הזמן בעת קביעת גודל מערכות ברוויט - כלי סימולציית ביצועי בניין בודקים תכנון מול אותם מדדים הרבה לפני שמערכת מכנית ממודלת במלואה.
במקום לייצא טבלה סטטית מרוויט, שמאי כמויות יכול לחבר את Assemble ישירות למודל החי ולפרוס כמויות לפי כל תנאי שנדרש עבור חבילת מכרז ספציפית - שכבה מהירה וגמישה יותר מעל אותם נתוני מודל בסיסיים שהטבלאות של רוויט עצמו משתמשות בהם.
פאנל בטון טרום או תא אמבטיה טרום-מיוצר מתאימים באופן טבעי להרכבה (Assembly) - הם זקוקים לתצוגות פירוט משלהם ולגיליון בסגנון שרטוט ייצור עבור היצרן, וזה בדיוק מה שהרכבה מייצרת אוטומטית, בשונה מקבוצה פשוטה שאין לה תשתית תצוגות/גיליונות משלה.
זהו השדה שמאפשר לטבלה לסכם כמויות לפי מערכת בנייה - כל אסמבלי קיר חיצוני יחד, למשל - ולא רק לפי הקטגוריה המובנית של Revit עצמה.
סקר מצב מבנה הוא ההערכה החד-פעמית שמפיקה אותו; הדירוג עצמו הוא מה שבפועל מזין את ההחלטה של צוות ניהול מתקנים לגבי איזה גג להחליף השנה לעומת איזה יכול לחכות.
זהו הסיום הפורמלי של מחזור החיים של נכס - בלעדיו, דוד שהוצא משירות יכול להמשיך לשבת במרשם הנכסים כאילו הוא עדיין משהו שניהול מתקנים צריך לתחזק.
המשמעת הרחבה יותר שה-7D וה-AIM של BIM קיימים כדי לתמוך בה: העבודה המתמשכת ולאורך כל מחזור החיים של תפעול, תחזוקה ובסופו של דבר החלפה של מערכות ורכיבי מבנה, זמן רב לאחר שהבנייה מסתיימת. ניהול נכסים חושב בעשורים, לא באבני דרך של פרויקט - לוחות תחזוקה, מחזורי החלפה, ביצועי אנרגיה, בדיקות תאימות, הכל נעקב מול הנכסים הפיזיים בפועל שצוות ניהול המתקן אחראי עליהם.
בעוד ש-BIM התמקד באופן מסורתי בהקמת מבנה, החפיפה הגוברת בין BIM לניהול נכסים (דרך ה-AIM ותקנים כמו חלק 3 של ISO 19650) היא מה שהופך מודל חד-פעמי לכלי תפעולי ארוך-טווח במקום קובץ שמועבר לארכיון ביום שהמבנה נפתח.
בעוד ש-EIR ו-AIM עוסקים במידע שהמבנה נושא, תוכנית ניהול הנכסים עוסקת בהחלטות שאותו מידע אמור לתמוך בהן - מתי להחליף פריט ציוד, כיצד לתקצב עלויות מחזור חיים, לאילו חלקים בנכסים להשקיע הבא. תקן ISO 55000 קובע את הסטנדרט הבינלאומי שביחס אליו היא בדרך כלל נבנית.
זהו עמוד השדרה המעשי שעליו מערכת FM רצה - כל הזמנת עבודה, לוח תחזוקה ומאמץ asset-tagging מצביע בסופו של דבר חזרה לשורה אחת במרשם הנכסים.
מנהל נכסים שסורק תג על יחידת טיפול אוויר על הגג אמור להגיע ישירות לנתוני המודל של אותו נכס בדיוק - סטטוס אחריות, היסטוריית תחזוקה, דף מפרט - וסוגר את הפער בין הבניין הפיזי לרשומה הדיגיטלית שלו, פער שחבילת מסירה בלבד לא פותרת.
בדיקת בריאות קובץ עמוקה ואיטית יותר מ-Purge - הפקודה Audit של Revit סורקת את כל מסד הנתונים של הפרויקט לאיתור שחיתות ואי-עקביות ברמה נמוכה שמצטברות לאורך חיי פרויקט ארוכים, בעיקר במודלים בעלי עבודה משותפת כבדה, ומתקנת מה שהיא יכולה. היא בדרך כלל מורצת כשקובץ מתחיל להתנהג מוזר (קריסות לא מוסברות, אלמנטים שלא נמחקים בניקיון) או כתחזוקה מונעת תקופתית בפרויקטים גדולים וארוכי-טווח.
Audit ו-Purge פותרים בעיות שונות - Purge מסיר תוכן לא בשימוש, Audit מתקן מבנה קובץ לא בריא - ופרויקט גדול ומתוחזק היטב בדרך כלל מריץ את שניהם בלוח זמנים קבוע במקום לחכות שמשהו יישבר בגלוי.
השינוי המנטלי המרכזי במעבר מ-AutoCAD לרוויט הוא שבCAD משרטטים קווים עצמאיים שמייצגים קיר, בעוד רוויט ממדל אובייקט קיר פרמטרי אמיתי שמייצר את הקווים האלה (וכל טבלה, חתך וכמות) אוטומטית - וזו הסיבה ש"הרגלי AutoCAD" כמו שרטוט פרטים ידני מאפס הם המקור הנפוץ ביותר לחיכוך אצל משתמשי רוויט חדשים.
כאן מעקב בעיות ומעקב התקדמות באמת קורים יום-יום באתר - אפליקציית הטאבלט שמנהל אתר פותח, לא תיאום התכנון ש-BIM 360 היה ידוע בו במקור.
Forma משלבת ניתוח סביבתי ומאסות מהיר ומבוסס-ענן (שמש, רוח, רעש) עבור החלטות תכנון מוקדמות, יחד עם מודולי ניהול מסמכים, העברת קבצים ומעקב סוגיות שבעבר היו תחת השם BIM 360/ACC - רוויט מתחבר אליה ישירות לשיתוף ותיאום מודל בענן.
כדאי לבדוק ב-health.autodesk.com ברגע שעבודה משותפת בענן, סנכרון, או העלאה ל-ACC פתאום מפסיקים להתנהג כרגיל - זו בדרך כלל הדרך המהירה ביותר לדעת אם הבעיה אצלכם או אצל אוטודסק, לפני שמבזבזים שעה על פתרון תקלות מקומי. הדשבורד עוקב אחרי סטטוס של הרבה יותר ממאה שירותים נפרדים, אז כדאי לחפש את השירות הספציפי שבו אתם משתמשים (Revit Cloud Worksharing, BIM 360 Docs, APS) במקום לקרוא את כל הרשימה.
Insight שולף גיאומטריה ונתוני מיקום ישירות מתוך מודל הרוויט כדי להריץ ניתוח אנרגיה לבניין שלם בלי צורך במודל סימולציה ייעודי נפרד - שימושי לשאלות המהירות והאיטרטיביות של "מה אם היינו משנים את יחס החלונות" שעולות כל הזמן בתכנון מוקדם.
בסיס עלות שנקבע ב-design freeze הוא מה שכל הזמנת שינוי מאוחרת יותר נמדדת מולו - בלעדיו, "כמה הפרויקט הזה באמת גדל" אין נקודת התחלה קבועה לענות ממנה.
BIM Collaboration Format
הפורמט הפתוח להחלפת בעיות במודל - בלי לשלוח את המודל עצמו. קובץ BCF נושא הערה, צילום מסך, מיקום מצלמה והפניות לאלמנטים המדויקים המעורבים, כך שמי שמקבל אותו פותח את המודל שלו, קופץ ישר לבעיה ומתקן.
BCF מתוחזק על ידי buildingSMART (כמו IFC) ונתמך ב-Navisworks, ב-Solibri, בתוספי Revit וברוב פלטפורמות ניהול הבעיות. כך תוצאות זיהוי ההתנגשויות באמת עוברות בין צוותים.
זהו מושג בחוזים אמריקאים שרץ במקביל ל-practical completion בחוזים בריטיים - הרגע שבו סיכון ושימוש בפועל עוברים ללקוח, עם או בלי רשימת ליקויים.
BIM Execution Plan
תגובת צוות הפרויקט ל-EIR. ה-BEP נכתב על ידי המתכנן הראשי או מנהל ה-BIM ומסביר איך הצוות יספק את המידע שהלקוח ביקש.
קיימים שני סוגים:
כל פרויקט BIM רציני פועל על בסיס BEP.
מסמכי המכרז, תוכנית העלויות והתוכנית המוצעת של קבלן כולם נאספים תחת ניהול הצעות מחיר - הצעה שהוגשה בחיפזון היא מקור סיכון מוקדם ונפוץ שמרשם הסיכונים המאוחר יותר מסתיים במעקב אחריו.
Building Information Modeling
נקודת ההתחלה. BIM הוא לא תוכנה - הוא תהליך. הכוונה היא ליצור ולנהל את המידע של מבנה בצורה דיגיטלית לאורך כל מחזור חייו: תכנון, תיעוד, בנייה ותפעול.
בלב תהליך BIM עומד מודל תלת-מימדי שבו כל אלמנט נושא נתונים - לא רק גיאומטריה. קיר הוא לא רק צורה; יש לו חומר, דירוג אש, עלות וערך תרמי. הנתונים האלה נוסעים עם המודל משולחן האדריכל לאתר הבנייה ועד ללוח הבקרה של מנהל המתקן.
Autodesk Construction Cloud
פלטפורמת ניהול הבנייה בענן של Autodesk - שהושקה במקור כ-BIM 360, וכיום הבסיס ל-Autodesk Construction Cloud (ACC) - מכסה ניהול מסמכים, תיאום מודלים, עבודה משותפת בענן, מעקב בעיות שטח ועוד, הכל בסביבה אחת מחוברת. עבור צוותים רבים, זהו ה-CDE האמיתי והמעשי: המקום שבו מידע WIP, Shared, Published ו-Archive באמת חי, ולא רק מושג תיאורטי מ-ISO 19650.
עבודה משותפת בענן דרך הפלטפורמה הזו החליפה יותר ויותר את Revit Server עבור צוותים שמשתפים פעולה בין כמה משרדים, מכיוון שהיא לא צריכה חומרת שרת ייעודית ועובדת מכל מקום עם חיבור אינטרנט.
ל-BIM Champion אין בהכרח תפקיד רשמי עם המילה "BIM" בו - לרוב זהו פשוט האדם הכי נלהב ומיומן בצוות, שמסתיים במצב שבו הוא מכשיר עמיתים, דוחף לסטנדרטים טובים יותר, ותומך בכלים ובזרימות עבודה, הרבה לפני שהמשרד הופך את התפקיד הזה רשמית לתקן BIM Manager אמיתי.
התפקיד שמריץ את עבודת התיאום היומיומית והמעשית בפרויקט בודד: הקמת המודל המאוחד, הרצת זיהוי התנגשויות, מעקב וסגירת בעיות, בדיקה שמודלי הדיסציפלינות עומדים ב-LOD המוסכם בכל אבן דרך, ושמירה על המודל מאורגן בין פגישות תיאום.
בעוד שמנהל BIM קובע את הסטנדרטים והאסטרטגיה, מתאם BIM הוא זה שבפועל נמצא בתוך המודל כל יום ומוודא שהפרויקט עוקב אחריהם - שני התפקידים עובדים בצמוד, כשהמתאם מעלה בעיות שהמנהל צריך לפתור ברמה גבוהה יותר: בעיית חוזה, כשל תהליכי מתמשך, לקוח שדוחף נגד דרישות.
התפקיד האחראי על האופן שבו BIM בעצם נמסר - כתיבה ואכיפה של ה-BEP, הגדרת טמפלייטים וסטנדרטים ברמת המשרד והפרויקט, הדרכת צוות, וודאות שנתוני המודל שפרויקט מייצר בעצם עומדים ב-EIR של הלקוח. מנהל BIM פועל ברמה אסטרטגית: סטנדרטים ברמת המשרד, הטמעת תוכנה, שיפור תהליכים, לעיתים ניהול צוות של מתאמי BIM על פני כמה פרויקטים.
זה תפקיד שונה מהותית ממתאם BIM, שעובד בתוך התיאום היומיומי של מודל פרויקט אחד - אם כי במשרדים ופרויקטים קטנים יותר, לעיתים קרובות אדם אחד מסתיים חובש את שני הכובעים.
BIM Maturity Levels 0-3
סולם פשוט מ-0 עד 3 (מקבוצת המשימה הבריטית ל-BIM) שמתאר עד כמה פרויקט התרחק משרטוט 2D מבודד לכיוון BIM שיתופי ועשיר-נתונים במלואו:
רוב הפרויקטים האמיתיים כיום פועלים ברמה 2 - וזה בדיוק מה ש-ISO 19650 נכתב כדי לתקנן.
בין אם קוראים לו Family ברוויט, Component ב-ArchiCAD, או בלוק עם נתונים בכלי אחר - כל אלה הם אובייקטי BIM: גאומטריה בתוספת נתונים מובנים ופרמטריים (מידות, חומר, ביצועים, מפרט יצרן) ארוזים יחד כך שהם מתנהגים באופן עקבי בכל מקום שבו הם מוצבים. יצרנים יותר ויותר מפרסמים אובייקטי BIM משלהם כדי שהמוצרים האמיתיים שלהם יוכלו להיות מוגדרים ישירות בתוך מודל.
CIC BIM Protocol
נספח משפטי (הגרסה המוכרת ביותר פורסמה על ידי מועצת תעשיית הבנייה הבריטית) שמצורף לחוזה בנייה סטנדרטי כדי להפוך תוצרי BIM לאכיפים מבחינה משפטית. בפני עצמם, EIR או BEP הם מסמכים טכניים - אין להם משקל חוזי אלא אם כן משהו קושר אותם לחוזה בפועל. BIM Protocol הוא הקשר הזה: הוא מפנה ל-EIR/BEP, מגדיר מי הבעלים של נתוני המודל, קובע אחריות אם מידע שגוי או מאחר, והופך את מסירת המודל להתחייבות חוזית ולא לבקשה במאמץ סביר.
כל לקוח רציני שרוצה תוצרי BIM שבאמת ניתנים לאכיפה צריך פרוטוקול כזה לצד המסמכים הטכניים.
מונח כללי למומחיות BIM שמובאת מבחוץ: מנהלי מודלים, מדריכי BIM, יועצי BIM, מנחי BIM ומשרדי מידול/ביקורת - כולם נכנסים תחתיו. משרדים מביאים ספק שירותי BIM כשהם זקוקים ליכולת או קיבולת מקצועית שאין להם בתוך הארגון, במקום להעסיק מנהל BIM או רכז BIM קבוע.
במקום לשאול "האם אנחנו צריכים BIM", צוות פרויקט שואל "לאילו שימושי BIM אנחנו זקוקים" - כי מודל שנבנה להדמיית תכנון לא בהכרח מוכן ללוח זמנים 4D או לכימות כמויות. תכנון שימושי ה-BIM מראש (מושג שהופץ על ידי מדריך תכנון ה-BIM של אוניברסיטת פן סטייט) הוא האופן שבו תוכנית ביצוע BIM (BEP) קובעת איזו רמת פיתוח כל אלמנט באמת צריך.
זוהי לרוב התחנה הראשונה לבדוק שקובץ IFC שיוצא נפתח בפועל כראוי ונראה נכון, לפני שהוא נשלח הלאה ללקוח או לכלי תיאום כמו Solibri או Navisworks.
פלטפורמת תיאום שנבנתה במיוחד סביב חילופי בעיות BCF - במקום כלי בדיקת מודלים מלא כמו Solibri או Navisworks, BIMcollab מתמקד בהחלקת צד מעקב הבעיות של התיאום: יצירה, הקצאה, דיון וסגירה של בעיות BCF בסביבת עבודה משותפת ומובנית שמתחברת ל-Revit, Navisworks, Solibri ורוב כלי ה-BIM הגדולים האחרים.
זו דוגמה טובה לאיך openBIM באמת מתממש יום-יום: צוות יכול להשתמש בתוכנת מידול שונה לגמרי אחד מהשני ועדיין לתאם בצורה נקייה, כי הבעיה עצמה נוסעת כקובץ BCF תקני ולא נעולה לפלטפורמה של ספק אחד.
התווית הזו בדרך כלל מוצמדת לשיווק שטוען לעמידה ב"רמת BIM 2" או "BIM מלא", בעוד שהאספקה בפועל היא עדיין שרטוטים דו-ממדיים עם מודל תלת-ממדי סמלי, או חברה שמחזיקה רישיונות רוויט אך מעולם לא אימצה את סביבת ה-CDE השיתופית, התקנים ותהליכי ניהול המידע שהופכים את ה-BIM לעבוד בפועל.
היא כעת חובה עבור רוב הפיתוחים החדשים באנגליה, ומשתמשת במדד מתוקנן כדי לדרג ערך בית גידול לפני ואחרי - סטנדרט צעיר, אך כבר בלתי נמנע בבקשת תכנון כמו הערכת אנרגיה.
לבדו הוא לא יודע כלום על קירות או דירוגי אש - הוא כלי תלת-ממד כללי, לא פלטפורמת יצירת BIM - וזו בדיוק הסיבה שתוסף כמו BonsaiBIM קיים כדי לגשר על הפער הזה.
Bluebeam Revu
הרבה לפני שהתכנון מגיע לפירוט מלא במודל, בודקי תוכניות, קבלנים ולקוחות מסמנים גיליונות PDF מיוצאים ב-Bluebeam עם הערות, עננים ומדידות - זו הפכה לשכבת הביקורת הסטנדרטית בתעשייה, שיושבת מעל כלי ה-BIM עצמם ולא בתוכם.
Building Management System
מערכת הבקרה הממוחשבת שבפועל מפעילה את ציוד המכני והחשמלי של מבנה יום-יום - מיזוג אוויר, תאורה, בקרת גישה, לעיתים מערכות אש ואבטחה - עוקבת אחר חיישנים ומכווננת ציוד אוטומטית כדי לשמור על המבנה פועל ביעילות. נקראת גם BAS (Building Automation System) באזורים מסוימים.
ה-BMS הוא המקום שבו נתוני 7D ו-AIM של מבנה הופכים לתפעוליים באמת: תגי ציוד ונתוני מערכת שנתפסו במודל במהלך התכנון ונמסרו דרך COBie הם בדיוק מה ש-BMS צריך מוגדר נכון כדי בפועל לשלוט בפריט הציוד הנכון - מודל שנמסר בצורה גרועה אומר צוות ניהול מתקן שמתכנת ומתייג הכל מחדש ידנית לאחר האכלוס.
בניגוד ל-Revit או ArchiCAD, שמייצאים ל-IFC כמחשבה בדיעבד, BonsaiBIM שומר את הנתונים שלו כ-IFC באופן ילידי מההתחלה - גישה שונה באמת למה ש"open BIM" יכול לומר בפועל.
כתב כמויות
כאשר QTO הוא תהליך מדידת הכמויות מתוך מודל, כתב הכמויות הוא המסמך המתומחר שנוצר, שקבלנים משתמשים בו להגשת הצעות מחיר ולקוחות משתמשים בו להערכת עבודה שהושלמה - כתבי כמויות שמקורם ב-BIM מתעדכנים אוטומטית ככל שהתכנון משתנה, במקום לדרוש מדידה מחדש ידנית מלאה.
Building Research Establishment Environmental Assessment Method
המקבילה הבריטית ל-LEED - שיטת הערכה לבנייה ירוקה (מ-BRE) שמכסה אנרגיה, בריאות ורווחה, חומרים, פסולת ושימוש בקרקע, עם דירוגים מ-Pass ועד Outstanding. BREEAM שולט בפרויקטים בריטיים ובינלאומיים רבים באותו אופן ש-LEED שולט בצפון אמריקה, ושני התקנים מוזכרים לעיתים קרובות יחד כשתי המערכות המוכרות ביותר בעולם.
כמו LEED, BREEAM לא מחייב BIM, אך פרויקט ממודל היטב ועשיר-נתונים הופך את הרכבת הראיות שהערכת BREEAM דורשת למהירה בהרבה מאשר איסוף אותן מגיליונות ושרטוטים מפוזרים בדיעבד.
בפרויקט גדול עם מאות תצוגות, ארגון דפדפן מוגדר היטב (מקובץ לפי תחום ואז שלב, למשל) הוא לעיתים קרובות ההבדל בין מציאת התצוגה הנכונה תוך שניות לגלילה ברשימה לא ממוינת במשך דקה.
BS 1192:2007
התקן הבריטי שקדם אפילו ל-PAS 1192 - BS 1192:2007 הציג את מוסכמות מתן השמות והשכבות המשמעתיות והשיתופיות שתקני BIM מאוחרים יותר ירשו: קוד שמות עקבי (פרויקט-מקור-נפח-רמה-סוג-תפקיד-מספר), ורעיון של סביבת תיקיות משותפת ומובנית לצוות הפרויקט.
רוב מה שהתקן BS 1192 חלוץ בו מקופל כיום בתוך דרישות מתן השמות וה-CDE של ISO 19650, אך התקן עדיין מוזכר מדי פעם באופן ישיר, בעיקר בשל מוסכמת מתן השמות שלו, שמשרדים רבים בבריטניה ובעולם עדיין משתמשים בה כתבנית בסיס.
BS 7671: דרישות למתקנים חשמליים (תקנות החיווט של IET)
גודל כבלים, הגנת מעגלים ותיעול חיווט במודל חשמל ברוויט - כולם חוזרים בסופו של דבר לדרישות BS 7671 - מודל יכול להיראות שלם ועדיין להיכשל בבדיקה אם התכנון החשמלי הבסיסי לא באמת עומד בתקן.
BS 8536: תכנון וביצוע בניינים ותשתיות - קוד עבודה לניהול נכסים
BS 8536 מכניס את הצרכים של צוות ניהול הנכסים לתדריך כבר מהיום הראשון - סמיכויות חדרים, גישה לתחזוקה ואורך חיים צפוי של ציוד נתפסים לפני שהתכנון מתחיל, במקום להתגלות כבעיות אחרי שהבניין נמסר.
אובייקטי ספרייה לארכיטקטורה, הנדסה ובנייה - חלק 1: זיהוי וסיווג
זהו התקן שמאחורי הרעיון של קוד אובייקט קבוע ומובנה - בדיוק סוג המשמעת בשמות שעליה בנויה ספריית משפחות מנוהלת היטב, כולל ספריית משפחות ה-Revit של האתר הזה עצמו.
buildingSMART Data Dictionary
זוהי התשובה המעשית לבעיית מילון הנתונים בקנה מידה תעשייתי - במקום שכל מדינה או ספק תוכנה יגדירו "דירוג אש" בדרכם שלהם, bSDD נותן לתהליכי עבודה מבוססי-IFC מקור משותף וניתן לשאילתה למה שתכונה בפועל אומרת.
טווח הקיום המלא שמבנה עובר: תדריך והיתכנות, תכנון, בנייה, מסירה, תפעול - בדרך כלל השלב הארוך ביותר בהרבה - ובסופו של דבר שיפוץ, חיזוק או הריסה. כל הצעת הערך של BIM נשענת על ציר הזמן הזה: מידע שנוצר בזול במהלך התכנון (שינוי קיר הוא טריוויאלי על המסך) הופך יקר באופן אקספוננציאלי ליצירה או לתיקון ככל שמאוחר יותר במחזור החיים משאירים אותו, וזו בדיוק הסיבה שהשקעת מאמץ מוקדם באיכות הנתונים משתלמת.
מערך הממדים (3D עד 10D) בעצם ממופה על מחזור החיים הזה בסדר - גיאומטריה, זמן ועלות במהלך המסירה, ואז נתוני אנרגיה, ניהול מתקן ובטיחות שנושאים את הפרויקט דרך עשרות שנות תפעול לאחר מכן.
בשונה ממדריך תפעול ותחזוקה סטטי שנמסר פעם אחת במסירה, יומן בניין נועד להיות מסמך חי שמתעדכן ככל שציוד מוחלף או אסטרטגיות הפעלה משתנות - דרישת Soft Landings שמתייחסת לתיעוד הבניין כמשהו שמזדקן יחד עם הבניין עצמו, לא כתוצר חד-פעמי.
סימולציית ביצועי בניין (BPS)
כלי סימולציה ייעודיים שולפים גיאומטריה, חומרים ונתוני מיקום מתוך רוויט כדי לבחון תרחישי "מה אם" - יחס חלון-קיר, עומק הצללה, גודל מערכות מיזוג - הרבה לפני שקיר אחד נבנה, ומתחברים יותר ויותר ישירות לדיווח פחמן גלום ותפעולי.
זהו המקור החוקי שמאחורי דרישות חוט הזהב ותיק בטיחות המבנה - לא רק פרקטיקה טובה מומלצת, אלא חובה חוקית עם השלכות משפטיות אמיתיות אם עושים את זה לא נכון.
תיק בטיחות חייב להישמר ולהתעדכן באופן פעיל לאורך כל תקופת האיכלוס, לא להיות מוגש בארכיון פעם אחת בסיום - הוא נשען ישירות על ה-Golden Thread של מידע בניין מדויק ומעודכן שנשאר מחובר לנכס הפיזי כל עוד הבניין קיים.
זהו תוצר מרכזי של soft landings - מבנה יכול להיות מושלם טכנית ועדיין לתפקד גרוע אם אף אחד שעובד בו בפועל לא מבין איך אמצעי החימום או התריסים אמורים לפעול.
"נכס בנוי" הוא אוצר המילים שתקן ISO 19650 משתמש בו עבור המבנה בפועל ברגע שהוא קיים, בשונה ממודלי המידע המתארים אותו. המונח מופיע לאורך דיוני ניהול נכסים ומסירה במיוחד כדי למנוע בלבול בין "הבניין" לבין "המודל של הבניין".
תצוגת פירוט נשארת מקושרת לתצוגת האם שלה - מזיזים קיר בתוכנית, ותצוגת הפירוט החתוכה מתעדכנת יחד איתו - וזה מה שהופך אותה לכלי הנכון לפרט חתך קיר או פרט מדרגות, במקום לשרטט תצוגה כפולה מנותקת שהייתה יוצאת מסנכרון בשקט.
זוהי נקודת ההתחלה עבור walkthrough - תצוגת מצלמה סטטית בודדת היא פריים אחד; walkthrough הוא נתיב שלם שלהם שמונפש יחד.
זוהי פרקטיקת המדידה שהפחמן הגלום והפחמן לאורך מחזור החיים הם הנושא שלה - בלי חשבונאות פחמן מובנית במודל ובתהליך הרכש, יעד אפס-נטו נשאר שאיפה מוצהרת ולא מספר עוקב וניתן לאימות.
היא נועדה בכוונה להיות המפלט האחרון ברוב אסטרטגיות אפס-הנטו - חשבונאות פחמן קיימת בדיוק כדי להוכיח כמה הפחתה אמיתית קרתה קודם, לפני שקיזוז משמש לכסות את מה שנותר.
פרויקט יכול להיות רווחי בסך הכל ועדיין להיגמר לו הכסף באמצע אם תשלומים ועלויות לא מתוזמנים כראוי - וזה בדיוק הפער שתחזית תזרים מזומנים קיימת כדי לתפוס לפני שהוא הופך למשבר.
גימור קטגוריה A וקטגוריה B
מודל הבעלים בדרך כלל נעצר ב-Cat A, וקבלן הגימור של השוכר ממשיך משם במודל Cat B שלו - מה שאומר ששני המודלים זקוקים לממשקים נקיים ומוגדרים היטב (מערכת קואורדינטות משותפת וגבול היקף ברור) למרות שהם נבנים בזמנים שונים לחלוטין על ידי צוותים שונים לחלוטין.
Revit Category
הרמה הגבוהה ביותר בהיררכיית האלמנטים של Revit: קטגוריה ואז משפחה ואז טיפוס ואז מופע. כל אלמנט בפרויקט משתייך לקטגוריה אחת בדיוק - קירות, דלתות, חלונות, עמודים קונסטרוקטיביים, ציוד מכני - והקטגוריה שולטת בהתנהגות בסיסית: אילו פרמטרים זמינים, איך האלמנט מתוזמן, אילו עוביי קו וגרפיקה הוא מקבל כברירת מחדל, ובאילו תצוגות הוא מופיע.
קטגוריות קבועות על ידי Revit עצמו (אי אפשר להמציא חדשה), וזה בדיוק למה הן ממופות בצורה כה נקייה על מערכות סיווג חיצוניות כמו Uniclass או MasterFormat - הן נקודת העיגון היציבה שמאפשרת סיווג ותזמון אוטומטיים.
Common Data Environment
הפלטפורמה המשותפת היחידה שבה כל מידע הפרויקט מאוחסן, מנוהל ומופץ. במקום שקבצים יטוסו באימייל, הכל נמצא ב-CDE - מודלים, שרטוטים, מסמכים, התכתבויות.
ה-CDE מחלק את מידע הפרויקט לארבעה אזורים מרכזיים:
| אזור | מי ניגש | מה מכיל |
|---|---|---|
| WIP (עבודה בתהליך) | היוצר בלבד | עבודה שטרם הושלמה ואינה מוכנה לשיתוף |
| Shared (משותף) | צוות הפרויקט | מידע שאושר לתיאום |
| Published (מפורסם) | הלקוח ובעלי עניין | יעדים שסופקו רשמית |
| Archive (ארכיון) | כולם | גרסאות שבוטלו, שמורות לתיעוד |
תקנות הבנייה (תכנון וניהול)
CDM מזיז את האחריות לבטיחות אחורה בזמן - מתכננים חייבים לתכנן מראש כדי להוציא מהתכנון סכנות צפויות (נתיב גישה קשה, משימת תחזוקה שדורשת עבודה בגובה), במקום להשאיר את כל הפחתת הסיכון לקבלן באתר, וקובץ הבטיחות והבריאות הוא המסמך שמעביר את המידע הזה לשלב התפעול.
כאשר פרויקט רוויט משתמש ב-Worksets, קובץ אחד מוגדר כמודל המרכזי - הגרסה הסמכותית שאליה זורמים בסופו של דבר השינויים של כולם דרך Synchronize with Central. אסור לפתוח ולערוך אותו ישירות; במקום זאת כולם עובדים מתוך הקובץ המקומי שלהם.
זוהי הסגירה הפורמלית של תקופת אחריות הליקויים - המחויבות האחרונה שנותרה לקבלן לפני שכספי הריטנשן משוחררים במלואם. בלעדיה, ללקוח אין אישור מתועד שרשימת התיקונים אכן נסגרה ולא פשוט הוזנחה בשקט.
שמאי כמויות שמתמחר כביש או גשר מודד אותו מול CESMM4; אותו שמאי שמתמחר מבנה מודד אותו מול NRM במקום זאת.
התהליך הפורמלי לטיפול בשינוי תכנון ברגע שפרויקט כבר בעיצומו: הצעתו, הערכת ההשפעה שלו על עלות, לוח זמנים ודיסציפלינות אחרות, קבלת אישור פורמלי, ווידוא שכל מי שעובד מהמודל בעצם יודע שזה קרה. בלי Change Management ממושמע, שינוי "קטן" שנעשה על ידי צוות אחד יכול לשבור בשקט את העבודה המתואמת של צוות אחר, מכיוון שדבר לא הכריח את השינוי להיסקר או להיתקשר לפני שנחת במודל המשותף.
CDE מנוהל היטב תומך בניהול שינויים ישירות: העברת אלמנט ששונה דרך WIP ל-Shared היא בעצמה צורה של שינוי מבוקר וגלוי, במקום עריכה שפשוט מופיעה בשקט בסנכרון המודל הבא של מישהו אחר.
בעוד ניהול שינויים הוא התהליך השוטף של בקרה והערכה של שינויים מוצעים, הוראת שינוי היא המסמך החתום הספציפי שבפועל מאשר אחד מהם - נגרמת לעיתים קרובות על ידי התנגשות תיאום או תשובת RFI שחושפת שהתכנון המקורי לא ניתן לביצוע כפי שתועד.
בעוד ש-V-Ray בנוי לתמונות סטילס איכותיות במצב לא-מקוון, Vantage מחליף חלק מהנאמנות הזו באינטראקטיביות מיידית - קרוב ברוחו יותר ל-Enscape או Twinmotion מאשר למוצר האחות שלו עצמו.
Chartered Institution of Building Services Engineers
המדריכים שלו הם עבור מהנדסי MEP בערך מה ש-NRM הוא עבור שמאי כמויות - רפרנס שמאומץ בצורה כה נרחבת שתכנית תכנון שמפנה ל"הנחיות CIBSE" מובנת בדרך כלל ללא הסבר נוסף.
פילוסופיית תכנון ובנייה שמתמקדת בשמירת חומרים בשימוש כמה שיותר זמן - תכנון לפירוק במקום להריסה, פירוט חומרים ממוחזרים או ניתנים למחזור, והתייחסות לרכיבי מבנה כמשאב עתידי במקום פסולת בסופו של דבר. היא יושבת לצד צמצום פחמן גלום כאחד המנופים המרכזיים לצמצום טביעת הרגל הסביבתית של מבנה.
BIM תומך בחשיבת כלכלה מעגלית בדרך מאוד קונקרטית: מודל עם נתוני חומרים מדויקים הופך ל"דרכון חומרים" של המבנה - רשומה של בדיוק מה יש במבנה ואיפה, שהופכת פירוק, שימוש חוזר או מחזור עתידיים לבני-ביצוע באמת במקום ניחוש עשרות שנים מאוחר יותר.
בעוד ש-IFC ממדל מבנה בודד בפירוט עשיר, CityGML ממדל עיר שלמה באופן שטחי יותר - שניהם נפגשים בעבודת שילוב GIS-BIM, כל אחד מכסה את קנה המידה שהשני לא.
Autodesk Civil 3D
בעוד רוויט ממדל את הבניין, Civil 3D ממדל את כל מה שסביבו - כבישים, ניקוז, עבודות עפר ורשתות תשתית - ושתי התוכנות חולקות נתונים (לרוב דרך מערכת קואורדינטות משותפת) כך שיסודות הבניין ותכנון הפילוס נשארים מתואמים עם תוכנית האתר שסביבו.
זיהוי התנגשויות
התהליך של זיהוי אוטומטי של קונפליקטים בין אלמנטים ממודלי דיסציפלינות שונות. כאשר תעלת ה-MEP עוברת דרך הקורה של מהנדס הקונסטרוקציה, זיהוי ההתנגשויות מסמן זאת - דיגיטלית, במודל - לפני שהבעיה הופכת לעלויות גבוהות באתר.
זיהוי התנגשויות מופעל בכלים כמו Autodesk Navisworks או Solibri. קיימים שלושה סוגים:
Uniclass / OmniClass
כדי שמידע יהיה שמיש בין ארגונים, צריך שפה אחידה לקטלוג אלמנטים. Uniclass (בריטניה) ו-OmniClass (צפון אמריקה) הן מערכות סיווג היררכיות שנותנות לכל רכיב, מערכת ופעילות קוד תקני - מדלת בודדת ועד שלב פרויקט שלם.
הקודים מוזנים כפרמטרים באלמנטים ומאפשרים חיתוכי כמויות, מפרטים ודרישות מידע עקביים בין כל המשתתפים. תפגשו אותן בעיקר בפרויקטים בינלאומיים ובדרישות EIR של מזמינים גדולים.
היא מחליפה את הדרישה הישנה ל-Revit Server או רשת משרדית משותפת באותו תהליך עבודה של סנכרון עם מרכזי שצוותים כבר מכירים - ההבדל המשמעותי הוא היכן המודל המרכזי חי פיזית, לא איך משתמשים בפועל עובדים איתו יום-יום.
זהו מאפיין נפוץ של integrated project delivery ושיטות מסירה שיתופיות אחרות - התנגשות שנפתרת בשיחה של חמש דקות מעבר לשולחן משותף במקום שבוע של מיילים בין משרדים נפרדים היא בדיוק היתרון ש-co-location נועד ללכוד.
Construction Operations Building Information Exchange
פורמט נתונים מובנה להעברת מידע נכסים מצוות הבנייה לצוות ניהול המתקן עם השלמת הפרויקט. COBie מסופק בדרך כלל כגיליון אלקטרוני ומכיל כל מידע שמפעיל מבנה צריך: מרחבים, מערכות, ציוד, לוחות תחזוקה, אחריות וחלקי חילוף.
COBie הוא האופן שבו ממד ה-7D מסופק בפועל.
היתרים דיגיטליים הם הרעיון הזה שמובא כל הדרך לשולחן הרגולטור עצמו; רוב הפרויקטים עדיין מריצים גרסה שלו באופן פרטי קודם, ומשתמשים בכללי סגנון IDS כדי לתפוס הפרות לפני ההגשה.
בעוד שפרוטוקול BIM הוא תבנית סטנדרטית של סעיפים, הסכם שיתוף פעולה הוא המסמך החתום בפועל עבור פרויקט ספציפי, שמפרט את הגורמים האמיתיים ואת ההתחייבויות האמיתיות שלהם.
בלי כתב אחריות משני, בעלים עתידי או מלווה של בניין לא יהיה לו זכות חוזית ישירה לתבוע את האדריכל או הקבלן המקוריים אם מתגלה ליקוי - זהו המסמך המשפטי שנותן להם עמידה משפטית, נפרד מחוזה הבנייה הראשי ונפרד מאחריות מוצר (Warranty) שמכסה חומרים פיזיים.
זהו מאפיין נבדל מתצוגת מקרא כללית - סכימת הצבעים מוגדרת פעם אחת מול פרמטר (כמו שם מחלקה) וכל חדר שמתויג עם אותו ערך מקבל את הצבע שלו ואת הרשומה שלו במקרא באופן אוטומטי.
סוכן תיפעול ובדק מריץ מערכות מיזוג, חשמל ובטיחות אש דרך תנאי ההפעלה האמיתיים שלהן - לא רק בודק שהן מותקנות, אלא שהן מתפקדות לפי המפרט - והתוצאות מוזנות ישירות לתוך מדריך התפעול והתחזוקה ולקו הבסיס של צוות ניהול הנכסים למה ש"עובד כראוי" נראה כמוהו.
זה מה שלקוח אמור באמת לצפות לראות לפני הפעלת מערכות המבנה עבור משתמשים אמיתיים - לא רק מילת הקבלן שהבדיקה בוצעה.
היא קובעת לוח זמנים לאיזו מערכת נבדקת מתי ועל ידי מי, ומזינה ישירות את תעודת ההפעלה שמונפקת לאחר שכל בדיקה אכן עברה.
חוזי NEC מפרטים בדיוק אילו אירועים מזכים (שינוי שהונחה על ידי הלקוח, תנאי פיזי בלתי צפוי, ואחרים), ודורשים שהם יוערכו ויתומחרו במהירות - חלופה מובנית לתהליכי הזמנת שינוי ותביעה הפתוחים יותר הנהוגים במקומות אחרים.
עריכת המבנה המורכב של סוג קיר היא הדרך שבה מודליסט מגדיר ממה הוא בפועל עשוי, שכבה אחר שכבה - וזה מה שקובע את דירוג האש שלו, את הביצועים התרמיים, ואת כמויות החומרים שזורמות לטבלאות, במקום שהקיר יהיה סתם לוח גנרי בודד בלי היגיון בנייה אמיתי מאחוריו.
Massing
צורה תלת-ממדית מפושטת וחופשית-צורה המשמשת בסביבת התכנון הקונספטואלי של Revit לחקירת הצורה והמסה הכוללת של מבנה - טביעת רגל, גובה, נסיגות - לפני התחייבות לקירות, רצפות או גגות אמיתיים. ניתן להמיר פאות של מסה ישירות לאלמנטי מבנה אמיתיים ברגע שהצורה מתייצבת, כך שעבודת המסה המוקדמת לא נזרקת, היא הופכת לגיאומטריית ההתחלה של המודל האמיתי.
מסה היא גם המקום שבו הרבה ניתוח 6D מוקדם קורה - מחקרי שמש, חישובי שטח רצפה, מחקרי צל - כי היא מאפשרת לצוות תכנון לבדוק הרבה אופציות נפחיות במהירות, לפני שעלות המידול המפורט המלא הופכת שינויים ליקרים.
זהו אחד הנושאים השנויים ביותר במחלוקת בסכסוכי חוזי בנייה - תביעת הארכת זמן הופכת מסובכת באמת כששני הצדדים יכולים להצביע על עיכוב אמיתי שקורה באותם ימים בדיוק.
המודל המשותף ושיתוף העבודה (Worksharing) של BIM הופכים הנדסה במקביל למעשית: אדריכלים, מהנדסי קונסטרוקציה וצוותי MEP יכולים לפתח כל אחד את התחום שלו בו-זמנית על מודלים מקושרים או מבוססי Worksets, ולתפוס התנגשויות מוקדם דרך גילוי התנגשויות שוטף, במקום לגלות אותן בסוף שרשרת מסירה מסורתית ורציפה.
זהו לעיתים קרובות הצעד הראשון האמיתי בפרויקט retrofit או שיפוץ - ויותר ויותר נעשה באמצעות סריקת לייזר שמזינה ישירות מודל scan-to-BIM במקום סקיצה ידנית.
זה מה שמאפשר ל-Revit לנתב אוטומטית ריצת תעלה או צינור ולאמת שמערכת אכן רציפה - שני אלמנטים שנראים מחוברים בתצוגה אך לא חולקים מחבר אמיתי לא באמת מחוברים כלל.
היא מדרגת דברים שתוכנית האיכות של מבנה לא מכסה כלל - רעש, סדר באתר, איך מתייחסים לעובדים - שכבה תדמיתית שנמצאת לצד בדיקות הציות הטכניות הטהורות.
Constructability Review
עד כמה תכנון מעשי ובר-בנייה באמת בעולם האמיתי - האם ניתן להרכיב פרט פיזית ברצף המיועד, האם רכיב יכול לעבור דרך נתיב הגישה שהוא צריך כדי להגיע למיקומו הסופי, האם התכנון מניח סבילויות שבעלי המקצוע באתר באמת יכולים להשיג. Constructability Review פורמלי מביא מומחיות קבלנים ובעלי מקצוע לתהליך התכנון מוקדם, במיוחד כדי לתפוס את הבעיות האלה על המסך ולא באתר.
זיהוי התנגשויות תופס האם שני אלמנטים חופפים פיזית; סקירת בנאותיות תופסת את השאלה הרחבה והקשה יותר של האם תכנון שאין בו אפס התנגשויות גיאומטריות עדיין ניתן בפועל ומעשית לבנייה באופן שבו הוא שורטט.
נבנות עצמה היא האיכות הכללית שלתכנון יש או אין; בדיקת נבנות היא הפגישה הספציפית והמתוזמנת שבה מישהו בפועל בודק אותה לפני שמאוחר מדי לשנות.
זהו היסוד החוקי שבוררות (adjudication) בעצם נשענת עליו - בלעדיו, מסלול הסכסוך המהיר והחוקי שהבנייה נשענת עליו כה רבות לא היה קיים כזכות חוקית בכלל.
נכתב על ידי הקבלן הראשי לפני תחילת העבודה ונשמר חי לאורך כל הביצוע, הוא מכסה כללי אתר, סידורי רווחה, וכיצד סיכונים ספציפיים שזוהו בתכנון יבוקרו בפועל בשטח. זוהי דרישה חוקית בפרויקטים בבריטניה בכל גודל ממשי, לא תוספת אופציונלית.
בלעדיו, חוזה בסכום גלובלי הוא מספר יחיד ללא דרך לבדוק תשלומי התקדמות מול עבודה שבוצעה בפועל - ניתוח סכום החוזה הוא המסמך שכנגדו שמאי כמויות מעריך תעודות ביניים.
זהו קו אמצע נפוץ בין שני הקצוות - צוות הלקוח שומר על שליטת תכנון על רוב המבנה, בעוד הוא מוסר את החלקים המומחים למי שבאמת הכי מתאים לתכנן אותם.
מהנדס קונסטרוקציה משתמש בדרך כלל ב-Copy/Monitor כדי להביא את הרשתות והמפלסים של האדריכל למודל שלו עצמו, במקום לשרטט אותם מחדש ידנית - ואם האדריכל מזיז מאוחר יותר את הגובה של מפלס, רוויט מסמן את הפער אוטומטית במקום ששני המודלים יסטו זה מזה בשקט.
זוהי האחות הנגישה יותר של Chaos ל-V-Ray - פחות הגדרות לכוונן, במחיר מסוים של השליטה העדינה ש-V-Ray מציע לאמני הדמיה מנוסים.
תוכנית עלויות בשלב מוקדם עשויה להיות נתון בודד למ"ר; עד שהיא מגיעה לניתוח סכום החוזה היא מפורטת אלמנט אחר אלמנט - אותו מסמך שמבשיל לצד התכנון.
שמאי כמויות מקשר את CostX ישירות למודל הרוויט (או לקובץ IFC מיוצא), כך שכמויות נמדדות מתעדכנות אוטומטית ככל שהתכנון משתנה, במקום למדוד מחדש ידנית שרטוטים בכל פעם שמגיעה רוויזיה - אותה מטרה בסיסית כמו Assemble Systems, מכיוון של כלי שממוקד-ראשית באומדן עלויות ולא בתיאום מודל.
כל דבר בנתיב הקריטי משנה לתאריך הסיום; כל דבר מחוצה לו יש לו מרווח כלשהו - וזו בדיוק הסיבה שמנהל פרויקט טוב עוקב אחר הנתיב הקריטי הרבה יותר מקרוב משאר לוח הזמנים.
כיווץ תחום הגזירה של תוכנית קומה לאזור שגיליון צריך בלבד, במקום להציג את כל המודל באותו קנה מידה, הוא אחת הדרכים הבסיסיות ביותר שבהן משתמש Revit שולט במה שבאמת מודפס על גיליון שרטוט.
זהו שוער מעשי ויומיומי - שער האבטחה של אתר בודק אותו לפני שמישהו נכנס, בלי קשר לכמה טובה עבודתו בפועל.
במקום מארג קיר אחיד, קיר מסך מוגדר על ידי דוגמת רשת שמחלקת אותו לפאנלים (בדרך כלל זכוכית, אך ניתנים להחלפה לפאנל מלא או תריס), עם מוליונים לאורך קווי הרשת - מה שהופך אותו למערכת המובילה לכל דבר, מחזית חנות בודדת ועד חזית מגדל משרדים מזוגגת במלואה.
זוהי המקבילה ל-Join Geometry עבור אלמנטים שצריכים לעבור זה דרך זה במקום להתמזג - בלעדיו, תעלה שמנותבת דרך קיר פשוט תוצג כגוש מלא שמתנגש בו.
אם מגדירים אותו נמוך מדי בתוכנית קומה, אדן חלון נמוך לא יוצג כחתוך; אם מגדירים אותו גבוה מדי, הוא עלול לחתוך דרך משקוף דלת במקום הקיר שמתחתיו - זהו הערך הספציפי בתוך view range שרוב הבלבול בקריאת תוכניות באמת נובע ממנו.
הוא מתחרה ישירות באותו מרחב כמו Enscape, Lumion ו-Twinmotion - כלי הדמיה בזמן אמת שנבנו כדי לשבת לצד מודל היצירה ולא להחליף אותו.
בלי מילון נתונים משותף, "FireRating" של כלי אחד ו-"Fire_Rating_Class" של כלי אחר מתארים את אותה תכונה תחת שני שמות שונים, ושוברים כל בדיקה אוטומטית או מסירה. ה-bSDD של buildingSMART הוא הדוגמה הציבורית המוכרת ביותר, וממפה מערכות סיווג כמו Uniclass ו-OmniClass לרפרנס מקוון יחיד.
מונח מעולם ה-PAS 1192 / ISO 19650 עבור נקודה מתוזמנת בפרויקט שבה קבוצת מידע ספציפית שהוסכמה מראש חייבת להימסר לתוך ה-CDE - לא "שלחו כשמוכן" מעורפל, אלא אבן דרך קבועה הקשורה ל-MIDP של הפרויקט. פספוס Data Drop מטופל באותו אופן כמו פספוס כל דדליין חוזי אחר.
Data Drops הם מה שהופך את ה-MIDP וה-TIDP ליותר מלוח זמנים תיאורטי - הם נקודות הביקורת הקונקרטיות שצוות פרויקט באמת נמדד לפיהן, בדרך כלל מיושרות עם אבני דרך גדולות של הפרויקט כמו סוף שלב תכנון או אבן דרך בבנייה.
הפירוט הנכון תלוי במי ששואל - צוות FM שעוקב אחר החלפות מסננים צריך פירוט ברמת התעלה, בעוד שדוח עלויות ברמת תיק הנכסים משורת טוב יותר על ידי סיכום ברמת מערכת. LOD הוא פירוט שמוחל על גאומטריה; זהו אותו רעיון שמוחל על נתונים.
אם דירוג האש של חדר משתנה שלוש פעמים לאורך תכנון, ביצוע ומסירה, שושלת נתונים היא מה שמאפשר למישהו לעקוב אחורה כדי להבין איזה שינוי היה נכון ומי ביצע אותו.
מעבר בין תוכנות FM, או העברת מרשם נכסים ישן ל-AIM חדש, הוא בפני עצמו פרויקט הגירת נתונים - ובדיוק המקום שבו איכות נתונים לקויה במעלה הזרם הופכת לעבודת ניקוי יקרה מאוד.
בלי ניסוח חוזי ברור, לקוח יכול להישאר חסר יכולת חוקית לעדכן או אפילו לגשת במלואו למודל שעבורו שילם, וזו בדיוק הסיבה שמסמכי מינוי מודרניים (כמו BEP) מפרטים תנאי בעלות ורישוי על נתונים באופן מפורש בדיוק כפי שהם מפרטים שכר ותוצרים.
דלת שמעוצבת בצורה מושלמת עם שדה דירוג אש ריק היא בעלת גאומטריה מצוינת ואיכות נתונים לקויה - בדיוק סוג הפער שבדיקת איכות מודל ובדיקות data validation קיימות כדי לתפוס.
מילון נתונים או מערכת סיווג משותפת כמו Uniclass הם הכלים; תקנון נתונים הוא המשמעת המתמשכת של אכיפתם בפועל פרויקט אחר פרויקט, לא רק פרסום שלהם פעם אחת.
במקום שכל יצרן או מודליסט ימציא שמות תכונות משלו, למשל עבור דלת אש, תבנית נתונים (כמו סטנדרט אובייקטי ה-BIM של NBS בבריטניה) קובעת את הפרמטרים, היחידות וסוגי הערכים המדויקים הצפויים - וזה מה שהופך נתונים לבני-פעולה הדדית ולניתנים לחיפוש באמת בין פרויקטים ותוכנות, לא רק תואמים גאומטרית.
במקום שאדם יבדוק ידנית שלכל דלת בהגשה יש פרמטר דירוג אש מלא, כלי אימות מפעיל מערכת כללי IDS (או בודק דומה) באופן אוטומטי, ודוחה או מסמן כל אלמנט שלא עומד בדרישות המידע המוסכמות לפני שהוא מגיע בכלל למודל המשותף.
היא רצה על אותה גאומטריית מודל ששימושה מחקרי sun-path משתמשים בה, אך מתמקדת במדדי נוחות פנימיים במקום רק לעקוב אחר היכן צללים נופלים בחוץ.
זוהי האחות בעלת חשיבה-כלכלה-מעגלית של תכנון הריסה - איטית ויקרה יותר מראש, אך בדיוק מה שהופך material passporting ו-reverse logistics לכדאיים בהמשך.
ליקויים שנרשמים במהלך התקופה הזו נמעקבים באותו אופן כמו סוגיות שלפני המסירה - לרוב מול אותם אלמנטים במודל - וסגירת כולם היא בדרך כלל התנאי לשחרור כספי הביטחונות שהוחזקו מהתשלום הסופי לקבלן.
מרשם אזבסט וסקר מצב מבנה שניהם בדרך כלל מגיעים לפני שתכנון הריסה מתחיל, מכיוון שמה שבאמת נמצא במבנה משנה כיצד ניתן לפרק אותו בבטחה.
עותק "Duplicate" רגיל הוא תצוגה עצמאית לגמרי; תצוגה תלויה נשארת קשורה להורה שלה, וזה בדיוק מה שנדרש כשאותה תוכנית קומה גדולה צריכה להופיע מפוצלת לרוחב matchlines על פני מספר גיליונות.
זהו הנרטיב שמצדיק את השרטוטים - ומסביר למה מבנה נראה ויושב באופן שבו הוא נראה ויושב, לא רק מראה שכך הוא.
מכיוון שגורם אחד שולט גם בתכנון וגם בביצוע, Design and Build נוטה לרכז את קבלת ההחלטות והסיכון של BIM אצל הקבלן - ניגוד חד למול Design-Bid-Build, שבו צוות התכנון של הלקוח עצמו וקבלן שממונה בנפרד צריכים לתאם על פני גבול ארגוני ש-Design and Build מסיר ברובו.
גובה קומה נדיב ורשת מבנית שלא נלחמת בקירות מחיצה עתידיים הן שתיהן החלטות תכנון-להתאמה - זולות לקבל בשלב התכנון, יקרות לבצע retrofit עליהן מאוחר יותר.
זהו החצי בשלב התכנון של ההיגיון שמאחורי תקנות ה-CDM - מתכנן שבוחר פאנל חיפוי קל יותר ששני אנשים יכולים להרים בבטיחות, במקום כזה שדורש מנוף והרמה בסיכון גבוה יותר, הוא תכנון לבטיחות בפועל.
בלי הקפאת תכנון, צוותי ההמשך - יצרנים, מעריכי עלויות, מהנדסי קונסטרוקציה שמריצים ניתוח - עובדים תמיד מול מטרה נעה. הקפאת חבילה מוגדרת (למשל, מעטפת הבניין) ברמת LOD מוסכמת מאפשרת לצוותים האלה להתחייב על משאבים בלי לעשות מחדש את העבודה בכל פעם שמישהו משנה קיר.
הכלי המובנה של Revit לחקירת כמה חלופות תכנון - פריסות לובי שונות, טיפולי חזית שונים - בתוך קובץ פרויקט יחיד, בלי לשכפל את כל המודל. אלמנטים מוקצים ל-Option Set (קבוצת בחירות שוללות הדדית) ול-Option ספציפי בתוכה; שאר המודל, מחוץ לכל קבוצת אופציות, נשאר "המודל הראשי" המשותף שכל אופציה חולקת.
זה שונה מהותית מהשוואת חלופות תכנון מלאות בתהליכים גנרטיביים או חישוביים - Design Options הוא ספציפית המנגנון הפנימי-לקובץ של Revit עצמו, המשמש בעיקר להשוואות קצרות-טווח וקטנות-היקף במהלך פיתוח התכנון ולא לחקר תרחישים מקבילים גדולים.
יותר ויותר מתקיים בתוך סביבת נתונים משותפת או צופה כמו Navisworks או BIM 360/ACC ולא סביב שרטוט מודפס, סקירת תכנון מאפשרת לכל דיסציפלינה לראות את אותו מודל מאוחד בו-זמנית ולרשום סוגיות (לרוב כקבצי BCF) ישירות מול האלמנטים שגורמים להן.
מכיוון שצוותי התכנון והביצוע הם ארגונים נפרדים תחת Design-Bid-Build, מסירת המודל ביניהם חייבת להיות מפורשת ומתועדת היטב (דרישות EIR/BEP ברורות חשובות יותר כאן) ולא מובנת מאליה - בשונה מ-Design and Build, שבו אחריות התכנון והביצוע כבר יושבות בתוך חוזה אחד.
בעוד אזור מוצבע רק ממלא צורה בדוגמת הצללה, רכיב פרט הוא משפחה אמיתית לשימוש חוזר עם גיאומטריה והתנהגות משלה (הוא יכול להיות גמיש, להיערך במערך ולשאת פרמטרים) - הכלי הנכון לכל דבר שצריך לחזור על עצמו באופן זהה על פני הרבה שרטוטי פרטים, כמו רצף בידוד או פרופיל איטום סטנדרטי.
פרט טיפוסי חוזר - מידות, תגיות וקווים דו-ממדיים סביב תנאי ביצוע חוזר - מתאים באופן טבעי לקבוצת פרט, המוחזקת בנפרד מקבוצות המודל התלת-ממדיות המשמשות למכלולים פיזיים חוזרים.
Coarse, Medium, Fine
אחד המונחים המבולבלים ביותר עבור מי שלמד גם LOD - והם באמת שני דברים שונים. Detail Level (גס, בינוני או עדין) הוא הגדרת תצוגה ברוויט לכל תצוגה בנפרד שקובעת כמה פירוט גרפי אלמנט מציג: קיר ב"גס" עשוי להישרטט כקו יחיד, אותו קיר ב"עדין" מציג כל שכבה של המבנה שלו.
LOD מתאר עד כמה נתוני המודל שמאחורי האלמנט אמינים ומפותחים - מושג אמיתי, פרויקט-רחב וחוצה-תוכנות. Detail Level עוסק אך ורק באיך אותו אלמנט מצויר על המסך בתצוגה ספציפית אחת, ואין לו שום קשר לתוכן המידע האמיתי של המודל. קיר יכול לשאת נתוני LOD 350 מלאים ועדיין להיות מוצג ב"גס" בתוכנית אתר בקנה מידה קטן.
Design for Manufacture & Assembly
Design for Manufacture and Assembly - הגישה שמאחורי ממד ה-10D. במקום לתכנן מבנה ואז לחשוב איך בונים אותו, מתכננים מראש לייצור מחוץ לאתר: אלמנטים מודולריים, מקטעי MEP טרומיים, חדרים רטובים מוכנים - שמיוצרים במפעל בדיוק גבוה ומורכבים באתר במהירות.
ה-BIM הוא תנאי הכרחי כאן: המודל חייב להגיע לרמת דיוק ייצורית (LOD 400) כדי שהמפעל יעבוד ישירות ממנו.
בפרויקטים עתירי תשתיות (רכבות, כבישים, תשתיות) נפוץ למצוא קובצי DGN לצד קבצי RVT ו-DWG, מכיוון שכלי Bentley חזקים במיוחד במגזר הזה - IFC הוא בדרך כלל הגשר הנייטרלי בין שתי המערכות.
CDE הוא הכלי המעשי שמיישם ניהול נכסים דיגיטליים בפרויקט; התחום עצמו רחב יותר, ומכסה הכל, מכללי שמות ועד מי מורשה לדרוס איזה קובץ.
זהו ההמשך המעשי, הממוקד-אספקת-פרויקטים, למסמכי מדיניות כמו דרישות ה-Golden Thread - פחות תקן טכני כמו ISO 19650 ויותר ספר שיטות מומלצות (מודלים תאומים, גישות פלטפורמה, תכנון מונחה-ייצור) שלקוחות ציבוריים מפנים אליו יותר ויותר בדרישות שלהם.
בעוד אינטראופרביליות פותרת את "האם תוכנה א' יכולה לקרוא את קובץ תוכנה ב' היום," המשכיות דיגיטלית פותרת את הבעיה הקשה יותר של "האם מידע הנכס הזה עדיין יהיה שמיש בעוד 20 שנה, אחרי שהתוכנה שיצרה אותו כבר לא קיימת." זו הסיבה שבעלי נכסים ארוכי-טווח מעדיפים יותר ויותר פורמטים פתוחים ומתועדים היטב (IFC, COBie) על פני קנייניים, לכל דבר שאמור לשרוד מעבר לערכת הכלים הנוכחית.
זוהי הפילוסופיה הרחבה יותר ש-ISO 19650, ה-AIM, וחוט הזהב כולם משרתים - המידע של מבנה שנשאר מדויק, מובנה ונגיש במשך עשרות שנים, לא רק מדויק מספיק כדי לעבור את המסירה.
נפוץ בהקשרי תשתיות וממשל (בייחוד באוסטרליה, בבריטניה, ויותר ויותר לצד BIM גם בבניינים), הנדסה דיגיטלית מתייחסת למודל כאל חלק אחד בלבד ממערכת אקולוגית דיגיטלית רחבה יותר הכוללת GIS, נתוני חיישנים, סימולציה וניתוח נתונים. בפועל, רוב הארגונים משתמשים ב"הנדסה דיגיטלית" וב-BIM כמעט לסירוגין, כאשר הנדסה דיגיטלית מדגישה את צינור נתוני ההנדסה יותר מאשר את תוכנת המידול.
זה מה שהופך את ה-DfMA לעבוד בפועל - המודל חייב להיות מדויק מספיק (בדרך כלל LOD 400) כך שמכונת מפעל תוכל לחתוך, לכרסם או להדפיס ישירות ממנו ללא שלב שרטוט אנושי מחדש באמצע.
CORENET של סינגפור ומספר תוכניות פיילוט בארה"ב ובאירופה כבר הופכים חלקים מבדיקת התכניות לאוטומטיים בדרך זו - קוראים בדיקות מבוססות-כללים (כמו מרחקי מילוט מאש או מרווחי נגישות) ישירות מהנתונים של המודל עצמו במקום בודק אנושי שמודד PDF ידנית.
סימולציית רצף 4D, הדמיית הרמת מנוף או הרצה וירטואלית של תהליך הפעלה - כולן צורות של חזרה דיגיטלית, שתופסות התנגשות בין קבלנים, נתיב גישה חסום או שגיאה ברצף הפעלה על המסך במקום באתר, שם התיקון עולה הרבה יותר.
היא הכי חשובה כשמחלוקת קורית חודשים אחר כך - רשומה דיגיטלית ניתנת לחיפוש ומתוארכת קשה הרבה יותר לערער עליה מזיכרון של מישהו לגבי מה שיומן כתוב ביד אמר.
שרשור דיגיטלי אומר שכל פיסת מידע - מהחלטת תכנון מוקדמת ועד קריאת חיישן על נכס מותקן שנים אחר כך - נשארת מקושרת וניתנת למעקב חזרה למקור שלה, במקום להיווצר מחדש או ללכת לאיבוד בכל מסירה בפרויקט. זהו הרקמה המחברת שמאפשרת לתאום דיגיטלי (Digital Twin) לשקף באמת את המציאות, במקום להיות תמונת מצב חד-פעמית.
תאום דיגיטלי
העתק וירטואלי חי של מבנה פיזי, המתעדכן ברציפות עם נתוני עולם אמיתי מחיישני IoT ומערכות ניהול בניינים. בניגוד למודל BIM סטטי, תאום דיגיטלי מתפתח לאחר המסירה - עוקב אחר צריכת אנרגיה, בריאות ציוד, דפוסי תפוסה וצרכי תחזוקה בזמן אמת.
תאומים דיגיטליים הם נקודת הסיום של מחזור חיי BIM: המודל לא מועבר לארכיון כשהמבנה נפתח. הוא הופך לפלטפורמת המודיעין התפעולית לאורך כל חיי המבנה.
מודל או סקר שמתעד את מצב השטח בתחילת החכירה מול סיומה הוא הראיה המעשית מאחורי תביעת Dilapidations - אותן טכניקות לכידת מציאות ו-Scan-to-BIM שמשמשות לסקרי as-built של בניין חדש חלות גם כאן, רק בקצה השני של החכירה.
הוספה או הסרה של קו עדות משרשרת מידות קיימת שומרת אוטומטית על יישור כל שאר המקטעים - הצבה ידנית של אותו מספר מידות נפרדות כמעט אף פעם לא מתיישרת בצורה נקייה כזו.
תוכנית עבודה דיגיטלית
במקום שבו תוכנית עבודה מסורתית היא מסמך, תוכנית עבודה דיגיטלית היא נתונים מובנים - היא קושרת כל שלב בפרויקט (ראו RIBA Plan of Work) לנקודות מסירת נתונים מוגדרות, אחריות וסיווג, כך שכלי תוכנה יכולים לעקוב אחר מה נדרש, ממי, ומתי, במקום שצוות הפרויקט יעקוב אחרי זה ידנית בגיליון אלקטרוני.
פרט איטום סטנדרטי שחל באותה צורה בכל פרויקט מתאים באופן טבעי כאן - בניגוד ל-callout view, הוא אף פעם לא מתעדכן מהמודל כי הוא אף פעם לא היה מקושר אליו מלכתחילה.
זוהי לעיתים קרובות הדרך המהירה ביותר להזין פוטוגרמטריה בכמות התמונות החופפות שהיא צריכה, במיוחד באתר גדול או קשה לגישה.
זוהי התשובה של Autodesk לייצוא אוניברסלי לצפייה וסימון בלבד - קטן בהרבה מ-RVT או DWG מקוריים, ניתן לצפייה בכלים חינמיים, ולא ניתן לעריכה חזרה למודל המקור. שימושי לחבילות בדיקה שנשלחות לאנשים שלא צריכים (או שלא אמורים לקבל) גישת עריכה.
פורמט הקובץ הבינארי הילידי של AutoCAD, ובהרחבה אחד הפורמטים הנפוצים ביותר להחלפת מידע שרטוטי 2D בבנייה, גם בפרויקט עתיר-BIM. Revit יכול לייצא דפים ותצוגות ל-DWG עבור יועצים שעדיין עובדים ב-CAD דו-ממדי, או כדי לעמוד בדרישת חוזה לתוצרי DWG.
DWG הוא לא פורמט BIM - הוא נושא קווים, קשתות ובלוקים, לא אלמנטים פרמטריים או נתונים עשירים - כך שייצוא ל-DWG הוא בפועל צעד מטה בעושר המידע. הוא נותר חיוני בפועל כי הרבה קבלנים, רשויות ויועצי משנה עדיין מצפים לשרטוטים ב-DWG ולא ב-IFC.
פורמט להחלפת שרטוטים
מכיוון שהמבנה של DXF מפורסם בפתיחות וקריא כטקסט, זו הבחירה הבטוחה יותר בעת החלפת נתוני שרטוט דו-ממדיים עם תוכנה שאולי לא תומכת במלואה בפורמט הבינארי הקנייני של DWG - במחיר גדלי קבצים גדולים יותר ואובדן מדי פעם של עיצוב ספציפי ל-DWG.
Computational Design
להפסיק לעשות ביד את מה שמחשב עושה טוב יותר. תכנון חישובי מגדיר גיאומטריה ונתונים באמצעות לוגיקה וכללים במקום קליקים - Dynamo הוא כלי התכנות הוויזואלי של עולם Revit (ו-Python או C# דרך ה-API למתקדמים). שימושים יומיומיים: שינוי שם למאות גיליונות בבת אחת, בדיקות QA/QC אוטומטיות, ומילוי פרמטרים מטבלת אקסל.
תכנון גנרטיבי (Generative Design) לוקח את זה צעד קדימה - המחשב מציע ובוחן עשרות חלופות לפי יעדים שהגדרתם.
הוא נמצא בערך באותה רמה שבה Grasshopper נמצא עבור Rhino - גרירה וחיבור צמתים במקום כתיבת סקריפטים - והוא יכול לקרוא ולכתוב פרמטרים של Revit ישירות, מה שהופך אותו לגשר נפוץ בין תהליכי תכנון גנרטיבי למודל Revit חי.
לפני E57, לכל יצרן סורקים היה פורמט ענן נקודות קנייני משלו, מה שהקשה על העברת סריקה בין כלי לכידת מציאות ו-BIM שונים. כיום זהו הדבר הקרוב ביותר לתקן החלפה משותף שיש לתהליך scan-to-BIM, לצד LAS לנתוני LiDAR אוויריים וניידים.
מעורבות קבלן מוקדמת (ECI)
ECI מנסה ללכוד חלק מהתובנות המוקדמות של יכולת ביצוע ש-Design and Build מספק, תוך שמירה על שליטת צוות התכנון של הלקוח עצמו - הקבלן סוקר את המודל המתפתח, מסמן סוגיות יכולת ביצוע (ראו Constructability) מוקדם, ולעיתים קרובות מגבש תמחור לפני שהלקוח מתחייב לחוזה במחיר קבוע.
היא מובנית בפילוסופיה השיתופית של חוזה ה-NEC - סימון בעיה ברגע שהיא מזוהה, לפני שהיא הופכת ל-compensation event, נותן לשני הצדדים הזדמנות לנהל אותה יחד במקום להתווכח עליה בדיעבד.
היא עונה על שאלה חדה יותר מ"האם אנחנו בתקציב" - על ידי השוואת ערך מתוכנן, ערך נצבר ועלות בפועל יחד, היא מראה האם פרויקט הוא גם בלוח זמנים וגם בתקציב, או סוטה באחד בעוד שנראה בסדר בשני.
אם מודליסט צריך לערוך אלמנט שמישהו אחר כבר בבעלותו, רוויט שולח לאותו אדם בקשת עריכה שהוא יכול לאשר או לדחות - שכבת משא ומתן קלה שמאפשרת לצוות גדול לעבוד על אותו מודל מרכזי בו-זמנית בלי לנעול זה את זה כל הזמן.
Employer's Information Requirements
המסמך שמתחיל כל פרויקט BIM. ה-EIR נכתב על ידי הלקוח (המזמין) ומגדיר בדיוק איזה מידע הוא צריך מצוות הפרויקט - באיזה פורמט, לאיזו רמת פירוט, ובאילו אבני דרך של הפרויקט.
חשוב על זה כ"בריף BIM של הלקוח". הוא מכסה:
כל תהליך ה-BIM נגזר מה-EIR.
בלי הקצאת מכשירים למעגל, ל-Revit אין דרך ליצור טבלת לוח - זהו הקישור הבלתי נראה שהופך סט מפוזר של גופי תאורה למערכת חשמלית אמיתית על נייר.
פליטות הפחמן שקשורות לחומרי ותהליך הבנייה של מבנה - כרייה של חומרי גלם, ייצור מוצרים, הובלתם, ועבודת הבנייה עצמה - בניגוד לפחמן תפעולי, שמגיע מהפעלת המבנה המוגמר. עבור מבנה מודרני יעיל מאוד, פחמן גלום יכול לייצג נתח גדול יותר מפליטות אורך החיים מאשר פחמן תפעולי, פשוט כי צריכת האנרגיה התפעולית ירדה כל כך.
מודל BIM עם כמויות וסוגי חומרים מדויקים הוא הבסיס המעשי לחישוב פחמן גלום: הכפילו את הכמות של כל חומר (שנשלפת באותו אופן כמו כל QTO) בגורם הפחמן המפורסם שלו, והסכום הופך לקלט החלטת תכנון אמיתי במקום ניחוש שנעשה בדיעבד.
יצרן פלדה ללא הסמכת EN 1090 פשוט לא יכול לספק חוקית פלדה מבנית לשוק האירופי - זהו שער ציות קשיח, לא סימן איכות וולונטרי.
זוהי המתודולוגיה הפורמלית שמאחורי life cycle assessment - התקן שמגדיר בדיוק אילו שלבי מחזור חיים וקטגוריות השפעה נתון פחמן לאורך מחזור חיים בפועל חייב לקחת בחשבון.
הנחיות CIBSE בבריטניה ו-EN 16798 ברחבי אירופה מכסים חלק ניכר מאותו שטח של איכות סביבה פנימית, משני כיוונים מוסדיים שונים.
הוא מזין ישירות כלי סימולציית ביצועי מבנה כמו IES-VE או Autodesk Insight - מודל אדריכלי מלא כולל הרבה יותר פרטי גאומטריה ממה שסימולציית אנרגיה בפועל צריכה או יכולה לעבד ביעילות.
תעודת ביצועי אנרגיה (EPC)
בשונה מ-BREEAM, LEED או Passivhaus, שהן הסמכות וולונטריות שלקוח בוחר לשאוף אליהן, EPC היא לרוב דרישה חוקית מוצקה - ואותם נתוני מודל אנרגיה או סימולציית ביצועי בניין ששימשו לרדוף אחרי הסמכה וולונטרית מייצרים בדרך כלל את דירוג ה-EPC כתוצר לוואי.
תוסף רינדור בזמן אמת שרץ ישירות בתוך Revit (וכמה כלי BIM נוספים), והופך את המודל לסצנת תלת-ממד פוטו-ריאליסטית ניתנת להליכה כמעט מיידית - בלי ייצוא נפרד, בלי המתנה לסיום רינדור. תוך כדי עריכת המודל, תצוגת Enscape מתעדכנת חיה לצידו.
הערך המרכזי שלו הוא תקשורת: לקוח או קבלן שלא יודע לקרוא תוכנית קומה יכול לעבור בהליכה בתצוגת Enscape של אותו תכנון ולהבין אותו מיידית. הוא הפך כמעט לציפייה ברירת מחדל בפרויקטי Revit מול לקוחות, באותו אופן שהדמיה מרונדרת נהגה להיות תוצר מיוחד ומוזמן בנפרד.
היא נמצאת לצד תוכנית ניהול פסולת האתר כאחת משני המסמכים הסביבתיים שרוב אישורי התכנון כיום מתנים בהם.
דיווח סביבה, חברה וממשל (ESG)
חברת נדל"ן שמדווחת פחמן גלום ותפעולי על פני עשרות בניינים למשקיעים או לרגולטורים שואבת יותר ויותר את הנתונים האלה ישירות ממודל מידע הנכס של כל בניין, במקום להזמין ביקורת נפרדת - עוד סיבה שנתוני מודל מדויקים ומובנים ממשיכים להחזיר את ההשקעה הרבה אחרי המסירה.
Eurocodes - תקני התכנון הקונסטרוקטיבי האירופיים
Eurocode 1 מגדיר את העומסים, Eurocode 8 מכסה תכנון סייסמי וכן הלאה - מהנדס קונסטרוקציה מגדיר שילובי עומסים בכלי כמו Robot Structural Analysis לפי הקוד שחל על תחום השיפוט של הפרויקט, כאשר Eurocode הוא הנפוץ ביותר מחוץ לצפון אמריקה.
הארכת זמן (EOT)
מודל והיסטוריית לוח זמנים מתועדים היטב הם בדיוק מה שתביעת EOT צריכה כדי להוכיח את טענתה - הצגה מדויקת של מתי שינוי תכנון או מסירת מידע מאוחרת דחפו בפועל את רצף הביצוע אחורה, במקום שהעיכוב יהיה אשמת הקבלן עצמו.
משפחת תעלה גנרית מספיקה לתיאום תכנון; חלקי ייצור נושאים את נתוני היצרן האמיתיים הנדרשים לייצור דיגיטלי, ומזינים ישירות את תהליך החיתוך וההרכבה של המפעל.
השימושיות של BIM לא נגמרת במסירה - מודל מידע נכס (AIM) בנוי היטב, שמאוכלס דרך COBie או כלי דומה, מוזן ישירות לתוכנת ניהול מתקנים כך שבעלי הבניין יכולים לעקוב אחר נכסים, לתכנן תחזוקה ולנהל שטח בלי לסקור מחדש את הבניין. זו הסיבה המרכזית ביותר שבעלי נכסים גדולים מחייבים BIM בפרויקטים שלהם מלכתחילה.
Revit Families
לא מונח BIM כלל-תעשייתי, אבל המונח שכל משתמש Revit חי בתוכו. משפחה היא הגדרת רכיב פרמטרית - דלת, עמוד, גוף תאורה - עם טיפוסים (Types) (שילובי גודל ומאפיינים מוגדרים מראש) ומופעים (Instances) (האלמנטים שהונחו בפועל).
ב-Revit יש שלושה סוגים: משפחות מערכת (קירות, רצפות, גגות - מובנות בפרויקט), משפחות נטענות (קובצי rfa. שיוצרים או מורידים) ומשפחות In-Place (אלמנטים חד-פעמיים שממודלים ישירות בפרויקט). שליטה במשפחות היא הצעד הגדול ביותר מ"להשתמש ב-Revit" ל"לשלוט ב-Revit".
סביבת המידול הנפרדת בתוך Revit - שנפתחת על ידי עריכת משפחה ולא פרויקט - שבה משפחות באמת נבנות: קודם מישורי וקווי ייחוס, ואז גיאומטריה פרמטרית, טיפוסים ונוסחאות בשכבות מעל. היא נראית דומה לסביבת הפרויקט הראשית אך מתנהגת אחרת בדרכים חשובות, בעיקר שלקובץ משפחה אין עבודה משותפת והוא מיועד להתכופף ולהיבדק בבידוד לפני טעינה לפרויקט אמיתי.
נוחות ב-Family Editor היא בדרך כלל קו ההפרדה הברור ביותר בין מי ש"משתמש" ב-Revit לבין מי שבאמת יכול לפתור בעיות בו - רוב התסכולים היומיומיים מרכיב חסר או שגוי מתוקנים כאן, לא בקובץ הפרויקט.
זוהי המקבילה ברמת עורך המשפחה לפרמטרים פרויקטיים ומשותפים - נוסחת "רוחב פנל" של משפחת דלת היא פרמטר משפחה, והיא נשארת בלתי נראית לטבלאות ותגיות מחוץ לאותה משפחה עד שהיא מקודמת לפרמטר משותף.
בחירה ב"דלת" כתבנית משפחה מגדירה מראש התנהגות מארחות-קיר ופרמטרי דלת סטנדרטיים, בעוד בחירה ב"מודל גנרי מבוסס-פנים" מכינה משהו שיכול להתחבר לכל משטח - בחירת תבנית המשפחה הלא נכונה בהתחלה היא אחת הסיבות הנפוצות ביותר למשפחה מותאמת אישית שמתנהגת בצורה בלתי צפויה מאוחר יותר.
באיזה מהם צוות סקר משתמש בדרך כלל תלוי רק במותג הסורק שהם רכשו - שתי המערכות פותרות את אותה בעיית רישום בדרך דומה במידה רבה.
פורמט קובץ Filmbox (FBX)
רוויט יכול לייצא ישירות ל-FBX, שהוא הפורמט שרוב כלי ההדמיה ומנועי המשחק (כמו Unreal Engine, או Twinmotion בחלק מהצנרות עבודה) מצפים לקבל כקלט - שימושי כאשר מודל צריך לעבור מרינדור סטטי לחוויית הליכה אינטראקטיבית או VR.
מודל מאוחד
מודל משולב המורכב ממודלי דיסציפלינה נפרדים המקושרים יחד - מודל האדריכל, מודל מהנדס הקונסטרוקציה ומודל מהנדס ה-MEP נצפים בו-זמנית. אף אחד לא עובד באותו קובץ; במקום זאת, כל צוות עובד במודל שלו והמודל המאוחד מורכב לסקירות תיאום.
מודלים מאוחדים משמשים להפעלת זיהוי התנגשויות ולמתן תמונה מלאה של המבנה לכל בעלי העניין.
נקראת גם אסטרטגיית נפחים, היא קובעת כיצד המודלים מתחלקים - בדרך כלל לפי בניין, אזור ודיסציפלינה - כך שכמה צוותים יכולים למדל בו-זמנית בלי בעיות גודל קובץ או תיאום, ולאחר מכן מגדירה את ההיררכיה לקישור החלקים הללו חזרה למודלים מאוחדים, עד למודל מאוחד ראשי אחד לכל הפרויקט. בדרך כלל מתועדת כחלק מתוכנית ביצוע ה-BIM (BEP).
הפדרציה הבינלאומית של מהנדסים יועצים - טפסי חוזה סטנדרטיים
כל "ספר" FIDIC מתאים למודל התקשרות אחר - הספר האדום מתאים ל-Design-Bid-Build מסורתי עם פרויקט מתוכנן על ידי המזמין, הספר הצהוב מתאים ל-Design and Build, והספר הכסוף מתאים לפרויקטי EPC/מפתח בי - כך שאיזה ספר החוזה מפנה אליו אומר הרבה על מי נושא בסיכון התכנון עוד לפני שקוראים סעיף אחד.
זוהי המקבילה של FIDIC לפיצול מסורתי של design-bid-build - ה-Yellow Book, לעומת זאת, היא צורת ה-FIDIC לחוזים בסגנון design-and-build שבהם הקבלן גם מתכנן.
אזור מוצבע קיים רק בתצוגה שבה הוא צויר - אין לו עובי אמיתי או נוכחות תלת-ממדית - מה שהופך אותו לכלי הנכון לדברים כמו פושה (Poché), דוגמאות ריצוף בתוכנית, או אזור מודגש שלא אמור להשפיע על כמויות או טבלאות כפי שאלמנט מודל אמיתי היה משפיע.
הסכמה על החשבון הסופי היא לעיתים קרובות החלק האיטי ביותר בסגירת פרויקט - כל הזמנת שינוי, הארכת זמן ותביעת הפסד והוצאה צריכה להיות מותאמת מול סכום החוזה המקורי לפני ששני הצדדים חותמים.
ניתוח אלמנטים סופיים (FEA)
מהנדס קונסטרוקציה מוציא את המודל האנליטי (ראו מודל אנליטי קונסטרוקטיבי) מרוויט לכלי FEA ייעודי כמו Robot Structural Analysis, שמחלק את האלמנטים לרשת של חלקים קטנים ופותר את הפיזיקה עבור כל אחד מהם - השיטה הסטנדרטית מאחורי כל בדיקת עומס, התעוותות ועמידה בתקן מודרנית.
זהו מסמך חי וספציפי למבנה ולא בדיקת תכנון חד-פעמית - ועבור מבנים בסיכון גבוה, הוא כעת חייב להישאר עדכני כחלק מחוט הזהב.
עבור מבנים בסיכון גבוה, מידע זה מזין ישירות את "חוט הזהב" ואת תיק בטיחות המבנה - מידע בטיחות אש לא יכול להיות PDF סטטי שנמסר פעם אחת, הוא חייב להישאר מדויק ככל שהמבנה משתנה לאורך כל חייו.
זוהי הדרישה החוקית שהופכת הערכת סיכוני אש לחובה ולא לאופציונלית - חוק בטיחות המבנים הוסיף שכבת חובות נוספת מעליה ספציפית עבור מבנים בסיכון גבוה.
היא ממוקמת כחלופה נגישה יותר ל-WELL - תיעוד פחות ממצה, אך מכסה חלק ניכר מאותו שטח סביב אור, אוויר ונוחות משתמשים.
רוחב המשקוף של משפחת דלת יכול להיכתב כנוסחה שמפנה לרוחב הדלת הכולל ועוד היסט קבוע, כך ששינוי מידה אחת מעדכן אוטומטית את השנייה - המנגנון שגורם למשפחה פרמטרית בנויה היטב לזוז נכון במקום להישבר כשמשתמש משנה ערך בלתי צפוי.
נפוץ בעבודות ציבוריות, הסכם מסגרת קובע תעריפים סטנדרטיים ודרישות BIM/מידע פעם אחת, ולאחר מכן פרויקטים בודדים ("קריאות") מוענקים במהירות מולו - כלומר הסטנדרטים והתבניות של BIM במשרד צריכים להיות עקביים מספיק כדי לשרת פרויקטים רבים ושונים מאותה מסגרת, לא מותאמים לפרויקט אחד בלבד.
זהו פרויקט קטן ופחות בשל מ-Revit או ArchiCAD, אך הוא חלק אמיתי ומפותח באופן פעיל מאותה דחיפה קוד-פתוח לעבר openBIM כמו BonsaiBIM.
Fuzor יושב בצומת שבין הדמיה ותזמון - צוות פרויקט יכול לעבור במודל ב-VR תוך גלילה בו-זמנית בציר הזמן של הביצוע, מה שהופך אותו לבחירה פופולרית לתכנון לוגיסטיקת אתר ולהצגות לבעלי עניין שצריכות להראות גם "איך זה נראה" וגם "מתי זה קורה" יחד.
מגדירים את הקלטים (למשל, גבול מגרש ותוכנית חדרים), את המטרות (מקסום אור יום, מזעור מרחקי הליכה) ואת האילוצים, ותכנון גנרטיבי מפיק מגוון פריסות אפשריות המדורגות מול המטרות הללו - ומאפשר לצוות לחקור הרבה יותר אפשרויות ממה שחזרה ידנית הייתה מאפשרת. הוא נבנה על אותו מנוע תכנון חישובי בסיסי כמו Dynamo, אך ארוז כתהליך עבודה מודרך ומכוון מטרה במקום כתסריט חזותי פתוח.
Shared Site
הגדרת המיקום האמיתי בעולם האמיתי של פרויקט - קו רוחב, קו אורך וצפון אמיתי - כך שהמודל יושב נכון על מפה ומחקרי השמש והצל שלו מחושבים במדויק עבור המיקום האמיתי שלו. תכונת Shared Site של Revit מאפשרת לכמה פרויקטים מקושרים להסכים על עיגון אחד משותף בעולם האמיתי, וזה חשוב באתרי בנייה גדולים ורבי-מבנים או פרויקטי תשתית שפרושים על שטח רחב.
Geolocation וקואורדינטות משותפות פותרים בעיות קשורות אך שונות: קואורדינטות משותפות גורמות למודלים להסכים אחד עם השני, Geolocation גורם לכל הפרויקט להסכים עם כדור הארץ האמיתי - שניהם צריכים להיות נכונים כדי שמחקרי השמש, הקשר האתר ואינטגרציית GIS של מודל יהיו באמת בעלי משמעות.
לכל אלמנט ב-BIM יש שני סוגי מידע זה לצד זה: מידע גאומטרי (הצורה התלת-ממדית והמיקום שלו) ומידע לא-גאומטרי (כל השאר - יצרן, דירוג אש, קוד עלות). מודל יכול להיראות שלם מבחינה גאומטרית בעוד המידע הלא-גאומטרי בו עדיין ריק, וזה בדיוק הפער ש-EIR נכתב כדי לסגור.
החלוקה ל-Scope 1/2/3 שלו היא מה שרוב יעדי אפס-הנטו ומערכות חשבונאות הפחמן בבנייה בפועל בנויים סביבו, גם כשהפרויקט עצמו אף פעם לא מזכיר את הפרוטוקול ישירות.
מודל ה-BIM של מבנה בודד מדויק אך ממוקד; שכבת ה-GIS של עיר רחבה אך שטחית בפרטים - שילוב השניים מאפשר, למשל, לחברת תשתיות לראות בדיוק איזה צינור בתוך איזה מבנה מתחבר לאיזה קו ראשי ברמת הרחוב.
ערכים בעלי שם, ניתנים לשימוש חוזר (אורך, זווית, מספר, כן או לא) שחיים ברמת הפרויקט ולא בתוך משפחה בודדת, וניתן להשתמש בהם כדי להניע מידות, אילוצים ונוסחאות בכל מקום במודל. הגדרת "רוחב מסדרון סטנדרטי" כ-Global Parameter וקשירת כל מידת מסדרון אליו אומרים ששינוי הסטנדרט המשרדי פעם אחת מעדכן כל מסדרון בפרויקט מיידית, במקום לחפש כל אחד ידנית.
הם נקודת כניסה קלילה לאותה חשיבה של "הגדר פעם אחת, הנע הכל ממנה" שעליה בנויים מידול פרמטרי ופרמטרים משותפים, בלי צורך בגרף Dynamo כדי להקים אותה.
GL Transmission Format
פורמט תלת-ממד פתוח וללא תמלוגים (מתוחזק על ידי Khronos Group) שתוכנן במיוחד להיטען מהר בדפדפני אינטרנט, מנועי משחקים ואפליקציות AR/VR - משהו ש-IFC מעולם לא נבנה עבורו. glTF מפשיט מודל לגיאומטריה, חומרים ומרקמים קלילים, ומשמיט את נתוני הפרמטרים והסיווג העשירים ש-IFC נושא.
בתהליך BIM, glTF הוא בדרך כלל יעד ייצוא בקצה הצנרת: מודל מאוחד ומתואם מומר ל-glTF כדי שלקוח או צוות אתר יוכלו לצפות בו בצורה חלקה בטלפון או במשקפי VR, בלי צורך בתוכנת BIM כבדה.
מונח שנכנס לאוצר המילים של ה-BIM דרך רפורמת הבטיחות הבריטית בבניינים (בעקבות חקירת מגדל גרנפל): Golden Thread ("החוט המוזהב") הוא הדרישה שמידע קריטי לבטיחות על מבנה - אסטרטגיית אש, תכנון קונסטרוקטיבי, חומרים, שינויים מאוחרים - יישאר מדויק, נגיש ורציף מהתכנון דרך הבנייה ולאורך כל חיי המבנה.
זה פחות מסמך ספציפי ויותר עיקרון: מידע שנוצר בתכנון אסור שיאבד או יתיישן עד שהמבנה מאוכלס. BIM ו-CDE מנוהל היטב הם הכלים המעשיים שהופכים Golden Thread לבר-השגה - גיליון אקסל בתיבת הדואר של מישהו הוא לא.
בדומה ל-Dynamo ברוויט, Grasshopper מאפשר למתכננים לחבר צמתים זה לזה במקום לכתוב קוד כדי ליצור ולשלוט בגאומטריה מורכבת - חזיתות, אופטימיזציה קונסטרוקטיבית, חיפוש צורה - באופן פרמטרי. הוא דומיננטי במיוחד בתכנון מושגי מוקדם ובעבודות תחרות, שבהן לעיתים קרובות מעדיפים את המידול החופשי של Rhino על פני הכלים המוגבלים יותר של רוויט.
כמו קומה, זהו datum שצריך להיות ממוקם רק פעם אחת ונשאר עקבי בכל מקום - מהנדסים קונסטרוקטורים בפרט מנווטים סט שרטוטים כמעט לגמרי לפי הפניות רשת ולא לפי שמות חדרים.
הוא מעביר את סיכון חריגת העלות לקבלן, תוך שהוא עדיין מאפשר ללקוח ליהנות אם העלות בפועל מגיעה מתחת לתקרה - קו אמצע בין סכום גלובלי קבוע לחוזי החזר עלות בספרים פתוחים.
החזרת נכס היא למעשה השתקפות של המסירה המקורית - במקום נכס חדש שעובר מקבלן ללקוח, נכס מאוכלס כבר עובר בחזרה משוכר לבעלים, ומחלוקות על מצב השטח באותה נקודה הן בדיוק מה שתביעות Dilapidations עוסקות בהן.
הנקודה שבה פרויקט מפסיק להיות עבודת בנייה והופך למבנה מופעל: החזקה, והמידע הנלווה, עוברים באופן פורמלי מצוות המסירה ללקוח או למפעיל. בפרויקט מונע-BIM, מסירה היא לא רק מפתחות ותעודה - זה הרגע שבו החלקים הרלוונטיים של ה-PIM מסוננים ונמסרים כ-AIM, לעיתים קרובות ארוזים כנתוני COBie, לצד אחריות, מדריכים ורשומות עדות.
מסירה שהולכת רע בדרך כלל מתחקה לאחור ל-AIR שהוגדר בצורה גרועה בתחילת הפרויקט - אם אף אחד לא פירט מוקדם בדיוק אילו נתונים המפעיל צריך, אין דרך אמינה להרכיב אותם בלחץ דדליין בסוף.
זוהי קו ההגנה האחרון מול מצב הכשל הנפוץ שבו לקוח מגלה, חודשים אחר כך, שמסמך מסוים שהובטח מעולם לא נמסר בפועל.
רשימת הבדיקה היא כלי האימות; חבילת המסירה היא הדבר הפיזי או הדיגיטלי שמאומת - מדריך תפעולי ותחזוקתי, מדריך למשתמש במבנה ותעודת הפעלה הם תכנים טיפוסיים.
מדריך למשתמש במבנה הוא מסמך הייחוס; הכשרת מסירה היא המפגש החי שבאמת מוודא שמישהו קרא והבין אותו לפני שצוות התכנון הולך.
גם סכנות שהוצאו מהתכנון נרשמות כאן - אם אלמנט קונסטרוקטיבי מכיל אסבסט, או שלגג אין נקודות עיגון קבועות למניעת נפילה, זהו המסמך שחייב לציין זאת, ומלווה את המידע הזה מהתכנון ולאורך כל החיים התפעוליים של הבניין.
משפחת דלת מבוססת-מארח על קיר (מוחקים את הקיר והדלת נעלמת איתו), בעוד משפחה מבוססת-פנים יכולה להתחבר לכל משטח מתאים, ומשפחה עצמאית - כמו רוב הריהוט - לא זקוקה למארח בכלל. בחירת התנהגות המארחות הנכונה בעת בניית משפחה מותאמת אישית בעורך המשפחות קובעת עד כמה קל יהיה למקם ולהזיז אותה בהמשך.
זהו הגוף שיכול בפועל לעצור עבודה באתר או להעמיד קבלן לדין בגין הפרת בטיחות - תקנות ה-CDM הן הכללים; ה-HSE הוא מי שאוכף אותם.
עריכת מאות מספרי דלתות או שמות חדרים אחד אחד בתוך רוויט היא איטית ומועדת לטעויות - Ideate BIMLink שולף את הנתונים האלה לגיליון אלקטרוני מוכר, שבו חיפוש-והחלפה ונוסחאות הופכים שינויים בכמות גדולה למהירים, ולאחר מכן מחזיר את התוצאות בלי שאף אחד יגע ישירות באלמנטים במודל.
Information Delivery Specification
התקן הצעיר של buildingSMART, שהופך דרישות מידע ממסמכי Word לקובץ קריא-מכונה. במקום לכתוב "לכל דלת חייב להיות דירוג אש", קובץ ה-IDS מגדיר את הדרישה בצורה שתוכנה יכולה לבדוק אוטומטית מול מודל ה-IFC - ולסמן כל אלמנט שלא עומד בה.
בפועל: פחות ויכוחים על "מה נדרש", ובקרת איכות שהופכת מבדיקה ידנית לדוח אוטומטי.
Integrated Environmental Solutions Virtual Environment
בעוד שבדיקה מהירה בתוך רוויט עצמו עונה על "בערך כמה אנרגיה זה יצרוך," IES-VE נבנתה למידול המפורט והעומד בתקנים שגוף הסמכה או רגולטור בנייה דורשים בפועל - הגיאומטריה בדרך כלל מיוצאת או מקושרת מרוויט במקום להימודל פעם שנייה מאפס.
Industry Foundation Classes
פורמט הקובץ הפתוח להחלפת נתוני BIM בין פלטפורמות תוכנה שונות. IFC מאפשר לאדריכל שעובד ב-Revit לשלוח מודל למהנדס קונסטרוקציה שעובד ב-Tekla או לקבלן שעובד ב-Navisworks - ללא אובדן מידע.
IFC מתוחזק על ידי buildingSMART International והוא עמוד השדרה של BIM פתוח - העיקרון שתהליכי BIM לא צריכים להיות נעולים לאקוסיסטם התוכנה של ספק יחיד.
לפני 4.3, החלפת נתוני תשתית כ-open BIM משמעה מתיחת סכימה שממוקדת במבנים כדי להתאים לכביש או לגשר; 4.3 נותנת ליישורים, כבישים, מסילות ברזל ותחומי תשתית אחרים ישויות IFC משלהם באופן ראוי במקום זאת.
שרטוטים שהונפקו לביצוע
סטטוס ההנפקה הפורמלי שמסמן שרטוט כמשוחרר לקבלן ולצוות האתר כגרסה המחייבת לבנייה - בניגוד לסטטוסים מוקדמים יותר כמו For Review או For Coordination, שנועדו לבדיקה פנימית בלבד ולא היו אמורים לצאת מידי צוות התכנון מעולם.
שרטוטי IFC עוברים דרך אותו שער אישור ב-CDE כמו AFC Drawings, ובפרויקטים רבים שני התוויות מתארות את אותה אבן דרך משתי זוויות - IFC הוא מה שצוות האתר רואה מוטבע על הגיליון, AFC הוא איך שיומן מעקב הבעיות של צוות התכנון קורא לאירוע האישור. כאשר רוויזיה מאוחרת יותר מחליפה סט IFC, יש לסמן את השרטוטים המוחלפים כבטלים מיידית, מכיוון שקבלן משנה שעובד מגיליון IFC מיושן הוא אחד מכשלי התיאום הנפוצים והיקרים באתר.
הגרסה הראשית הנוכחית של IFC, שמחליפה את גרסת IFC2x3 השלטת זמן רב. IFC4 הוסיף תמיכה ביחסים פרמטריים עשירים יותר, נתוני ניתוח קונסטרוקטיבי טובים יותר, אלמנטי תשתית, והתאמה הדוקה יותר לתהליכי openBIM. בפועל, IFC2x3 עדיין מבוקש נרחבות בהרבה פרויקטים פשוט מהרגל תאימות תוכנה, כך שנפוץ לראות EIR שמפרט בדיוק איזו גרסת IFC - 2x3 או 4 - פרויקט חייב להשתמש בה, מכיוון ששתי הגרסאות אינן ניתנות להחלפה מלאה.
לדעת לשאול "איזו גרסת IFC?" במקום להניח ש"IFC" הוא דבר אחד יחיד היא פרט קטן שחוסך כאבי ראש תיאום אמיתיים.
רוב המשתמשים אף פעם לא נוגעים בה ישירות - זוהי הספרייה הבסיסית שמפתחים בונים עליה, באותה דרך שקוד של אתר תלוי בספריות שמבקר אף פעם לא רואה.
קובץ DWG או מודל מיובאים קפואים ברגע שהם מוכנסים - אם קובץ המקור משתנה, שום דבר לא מתעדכן - בעוד מודל מקושר נשאר מחובר ומתרענן אוטומטית, וזו הסיבה שמודלים מקושרים הם הסטנדרט לתיאום מתמשך רב-דיסציפלינות, וייבוא בדרך כלל שמור לגיאומטריית התייחסות חד-פעמית שלעולם לא תזדקק להתעדכן.
משפחה מקומית / מודל In-Place
מודל In-Place מהיר ליצירה אך מגיע עם עלויות אמיתיות: אי אפשר לשתף או לעשות בו שימוש חוזר בין פרויקטים, הוא נוטה לנפח את גודל הקובץ יותר ממשפחה שקולה, והוא לא גמיש באותו אופן דרך פרמטרים של עורך המשפחות - מתאים לאלמנט פיסולי ייחודי באמת, אך סימן נפוץ לזרימת עבודה חפוזה כשמשתמשים בו למשהו שחוזר על עצמו.
במקום לדבר על "קבצים" או "שרטוטים" באופן ספציפי, ISO 19650 משתמש ב"מכולת מידע" (Information Container) ככינוי נייטרלי מבחינת ספק ופורמט לכל פיסת מידע מנוהלת בפרויקט, כך שאותם כללים (שמות, סטטוס, גרסה, אישור) חלים באופן עקבי בין אם המכולה היא מודל רוויט, PDF או גיליון אלקטרוני.
הגשת מכרז, תוצר בשער שלב, וחבילת מסירה סופית הם כולם החלפות מידע - לא שיתוף קבצים אגבי, אלא אירוע מוגדר, נבדק ומתועד. כל תהליך ה-CDE של ISO 19650 קיים כדי להפוך כל החלפה לבת-ביקורת: מי הגיש מה, מתי, והאם זה עבר את הבדיקות הנדרשות.
המשמעת המטרייה ש-ISO 19650 קיים כדי לקודד: תכנון, ייצור, סקירה ושיתוף מאובטח של מידע לאורך חיי נכס בנוי, באמצעות תהליכים עקביים ולא הרגלים אד-הוק שמשתנים מצוות לצוות. זה רחב יותר מ"שימוש בתוכנת BIM" - ניהול מידע מכסה מוסכמות שמות, תהליכי אישור, סיווגי אבטחה, ותפקידים ואחריות שהופכים CDE לפעול באמת כמתוכנן, ולא רק להיות תיקייה משותפת עם שם מפוצץ יותר.
רוב ראשי התיבות במילון הזה - EIR, BEP, AIR, PIM, AIM, LOIN - הם כולם חלקים ספציפיים ממסגרת ניהול המידע ש-ISO 19650 מגדיר.
מוגדר בתקן ISO 19650, מנהל המידע הוא תפקיד פרוצדורלי - לא תפקיד תכנון או תיאום - ששולט בסביבת הנתונים המשותפת (CDE), מוודא שהמידע מוחלף לפי הפרוטוקול המוסכם, ומאשר שהתוצרים עומדים בדרישות המידע להחלפה של הפרויקט (EIR) לפני שהם עוברים בין מצבי ה-CDE. לתפקיד אין אחריות על גילוי התנגשויות או החלטות תכנון - הוא קיים אך ורק כדי לשמור על ניהול מידע ממושמע וניתן לביקורת.
"מודל מידע" הוא המונח הכולל שבו תקן ISO 19650 באמת משתמש - מודל מאוחד הוא דרך אחת לבנות אותו, אך מודל המידע כולל גם מסמכים, טבלאות ונתונים שלעולם לא מופיעים בתצוגה התלת-ממדית. בשלב הביצוע הוא נקרא PIM, ולאחר המסירה הוא הופך ל-AIM.
כל מסמך "דרישות מידע" עונה על אותן שלוש שאלות - מה, באיזו רמת פירוט, ועד מתי - רק מנקודת מבט שונה: ארגונית (OIR), נכס (AIR), פרויקט (PIR), או חילופי מידע עם ספק ספציפי (EIR). הבנת המשפחה כמכלול הופכת כל אחד מראשי התיבות הבודדים לקל הרבה יותר למקם.
גיליון נתוני ציוד של יועץ MEP שאף פעם לא מגיע למודל המשותף הוא סילו מידע קלאסי - בדיוק מצב הכשל ש-CDE ו"מקור אמת יחיד" נועדו לחסל.
אחריות רגילה טובה רק כמו החברה שהנפיקה אותה; IBG פותרת בדיוק את מקרה הכשל שבו אותה חברה כבר לא קיימת כדי לכבד את ההבטחה של עצמה.
הופצה על ידי ה-AIA בארה"ב, IPD היא נקודת הקצה בשיטת המסירה שגם target value design וגם co-location תומכות בה - החוזה הרב-צדדי הוא מה שבאמת מסיר את התמריץ מכל צד להגן על שולי הרווח שלו על חשבון הפרויקט.
מנהל הממשקים מזהה היכן המידע של צוות משימה אחד תלוי במידע של צוות אחר (למשל, כאשר מודלי הקונסטרוקציה והמערכות חייבים להתיישר), ומתאם את חילופי המידע כך שדבר לא נופל בין הכיסאות בין הדיסציפלינות. זהו תפקיד עתיר תקשורת, הפועל לצד מנהל צוות המשימה ומנהל מידע המשימה במבנה טיפוסי של צוות משימה ב-BIM.
בדיקת התנגשויות היא מבחן שפיות מהיר בתוך התוכנה - "האם התעלה הזו פוגעת בקורה הזו, בתוך הקובץ הבודד הזה" - בעוד גילוי התנגשויות מלא ב-Navisworks או Solibri מאחד מספר מודלים מקושרים מכל דיסציפלינה ומנהל את הסוגיות שנוצרות בקנה מידה של הפרויקט; רוב הצוותים משתמשים בשניהם, בשלבים שונים.
המטרה הרחבה שכל אחד מ-IFC, openBIM ופורמטים כמו glTF משרתים: היכולת של כלי תוכנה שונים - שנעשו על ידי ספקים שונים, משמשים דיסציפלינות שונות - להחליף נתוני מודל בלי לאבד או לפגוע במשמעות שלהם בדרך. אינטראופרביליות מושלמת קשה באמת: גיאומטריה בדרך כלל שורדת מעבר הלוך-חזור בין תוכנות, אך נתונים עשירים (פרמטרים, סיווגים, יחסים) הם בדיוק מה שנוטה להיאבד או להיפגע בתרגום.
כדאי להתייחס לזה כאל ספקטרום ולא כתכונה של כן או לא - "כמה אינטראופרבילי" חילוף נתונים מסוים בפועל תלוי מאוד באיזה זוג תוכנות ספציפי, איזה פורמט ואיזה נתונים שואלים עליהם.
Internet of Things
חיישנים ומכשירים מקושרים שמוטמעים ברחבי מבנה - חיישני תפוסה, ניטור טמפרטורה, מדי אנרגיה, תאורה חכמה - שמזינים ברציפות נתוני עולם אמיתי חזרה למערכות דיגיטליות. בהקשר BIM, IoT הוא מה שהופך מודל מסירה סטטי לתאום דיגיטלי חי: במקום תמונת מצב חד-פעמית מיום המסירה, המודל ממשיך לקבל נתונים תפעוליים אמיתיים לשארית חיי המבנה.
הערך המעשי מופיע בניהול מתקנים: BMS מחובר-IoT יכול לסמן פריט ציוד כושל לפני שהוא נשבר, או מנהל אנרגיה יכול להשוות ביצועים אמיתיים שנמדדו ב-IoT של מבנה מול יעדי האנרגיה שמודלו בתכנון 6D.
ISO 9001: מערכות ניהול איכות - דרישות
מסמכי מכרז של לקוח מבקשים לעיתים קרובות ממציעים להוכיח הסמכת ISO 9001 לצד יכולת ה-BIM שלהם - זהו אות בסיס לכך שלארגון יש תהליכים מתועדים וניתנים לחזרה, שעליהם תוכנית ביצוע BIM בונה לאחר מכן נהלי ניהול מידע ספציפיים לפרויקט.
ISO 14001: מערכות ניהול סביבתי
בעוד LEED או BREEAM מסמיכות את הביצועים הסביבתיים של הבניין המושלם, ISO 14001 מסמיכה את תהליכי ניהול הסביבה של הקבלן או משרד התכנון עצמם - טיפול בפסולת, שימוש במשאבים, מניעת זיהום באתר - שכבה שונה, ברמת הארגון, של אותה תמונת קיימות רחבה יותר.
בעוד ש-GHG Protocol הוא המסגרת המעשית והמאומצת בהרחבה שרוב הארגונים בפועל עוקבים אחריה, ISO 14064 הוא הגרסה התקנית הבינלאומית הפורמלית של אותו רעיון בסיסי.
התקן הבינלאומי לניהול מידע לאורך כל מחזור החיים של נכס בנוי באמצעות BIM. ISO 19650 מגדיר את העקרונות והדרישות עבור:
ISO 19650 הוא כיום תקן הייחוס הגלובלי ל-BIM, שהחליף תקנים לאומיים קודמים כסדרת PAS 1192 הבריטית.
ISO 19650-1: מושגים ועקרונות
ISO 19650-1 לא מגדיר בעצמו נהלים - הוא המילון המשותף והמסגרת המושגית שעליהם מתבססת שאר הסדרה, וכולל רעיונות כמו מיכל מידע, ארבעת מצבי סביבת הנתונים המשותפת, והעיקרון הכללי של ניהול מידע לאורך כל מחזור החיים של הנכס ולא רק בשלבי התכנון והביצוע.
ניהול מידע באמצעות BIM - חלק 2: שלב מסירת הנכסים
חלק 2 הוא הקטע ב-ISO 19650 שרוב הצוותים עובדים איתו יום-יום - הוא מגדיר את תהליך המינוי, EIR, BEP, MIDP/TIDP ותהליך העבודה של ה-CDE השולט באופן שבו מידע זז ממכרז ועד למסירה. חלק 3 ממשיך מהנקודה שבה הוא מסתיים, ומכסה את חיי התפעול של הבניין.
ניהול מידע באמצעות BIM - חלק 3: שלב התפעול של הנכסים
חלק 3 מיישם את אותה משמעת ניהול מידע כמו חלק 2 - מינויים, דרישות מידע, CDE - אך על ניהול מתקנים, שיפוץ ותפעול יומיומי במקום תכנון וביצוע, וסוגר את המעגל בין מודל מידע הנכס (AIM) של הפרויקט לבין חיי התפעול האמיתיים שלו.
ניהול מידע באמצעות BIM - חלק 5: גישה מודעת-אבטחה לניהול מידע
הוא חל על פרויקטים שבהם המידע עצמו עלול להיות סיכון אבטחה אם ידלוף - תשתיות קריטיות, אתרי ביטחון, מבנים בעלי פרופיל גבוה - ודורש הערכת רגישות מתועדת לפני החלטה עד כמה CDE יכול בפועל להיות משותף בפתיחות.
ISO 45001: מערכות ניהול בריאות ובטיחות תעסוקתית
הסמכת ISO 45001 של קבלן מדגימה גישה שיטתית לזיהוי סכנות והפחתת סיכונים - המקבילה הארגונית לביטול הסכנות בצד התכנון שתקנות CDM דורשות, וסוגרת את המעגל בין תכנון בטוח לביצוע בטוח.
ISO 55000: ניהול נכסים - סקירה, עקרונות ומינוח
בעוד ש-ISO 19650 קובע כיצד מנוהל המידע בשלבי התכנון והביצוע, ISO 55000 קובע את שלב ניהול הנכסים הארוך בהרבה שבא אחריו - ומיישר תקציבים, סיכונים ויעדי ביצועים על פני תיק שלם של בניינים, לא רק פרויקט בודד. מודל מידע נכס (AIM) בנוי היטב שנמסר בסיום פרויקט הוא מה שמאפשר לארגון שעומד בתקן ISO 55000 לנצל בפועל את המידע הזה בשלב התפעול.
המשמעת של הפיכת בעיית תיאום - התנגשות, פיסת מידע חסרה, קונפליקט תכנוני - לפריט במעקב עם בעלים, סטטוס ופתרון, במקום להשאיר אותה חיה רק בהערות פגישה או בזיכרון של מישהו. בעיות מוחלפות בדרך כלל בין צוותים כקובצי BCF, או מנוהלות ישירות בתוך פלטפורמת CDE, ופרויקט מנוהל היטב סוקר בעיות פתוחות בקצב קבוע עד שהמספר נוטה לאפס.
כל הרעיון של הרצת זיהוי התנגשויות ותיאום מודלים חסר ערך בלי מעקב בעיות ממושמע מאחוריו - מציאת מאה בעיות לא אומרת כלום אם ארבעים מהן בשקט אף פעם לא מתוקנות.
בעוד שחוזי NEC בנויים סביב ניהול סיכונים פרואקטיבי ושיתופי, חוזי JCT הם ברירת המחדל המסורתית והדומיננטית עדיין שרוב פרויקטי הבנייה בבריטניה בפועל משתמשים בה.
חיבורי קירות הם הגרסה האוטומטית והמיוחדת-לקירות של זה בפינות; Join Geometry הוא הכלי הידני לכל השאר - עמוד שנפגש עם רצפה, קורה שנפגשת עם קיר.
זוהי הגישה שמתחת לכל תנועת ה-lean construction - אותו היגיון ש-Last Planner System מיישם שבוע אחר שבוע, רק בשם הכללי ביותר שלו.
בעוד שתגית הערת מפתח בודדת בשרטוט מציגה רק קוד קצר, מקרא הערות המפתח הוא המפתח שמפרש מה כל קוד באמת אומר - נדרש כמעט בכל סט שרטוטי ביצוע שמשתמש ב-keynoting בכלל.
מערכת תיעוד שבה הערות שרטוט מפנות לקוד ממוספר מרשימת Keynote ראשית (לרוב קשורה למערכת סיווג כמו MasterFormat) במקום לכתוב טקסט חופשי ישירות על כל דף. תג על שרטוט מציג רק את הקוד; טקסט ההערה המלא חי ברשימה מרכזית וניתנת לעריכה אחת, כך שתיקון ניסוח הערה פעם אחת מעדכן אותה בכל מקום שאותו Keynote מופיע בכל הפרויקט.
זה בעצם המקבילה ברמת ההערות לפרמטרים משותפים: מקור טקסט מוסמך אחד, מופנה בכל מקום, במקום אותו ביטוי מוקלד מחדש באופן עצמאי על ארבעים דפים שונים עם ארבעים הזדמנויות לצאת מסונכרן במעט.
זוהי דרך קלת-משקל לשתף "איפה האתר הזה נמצא" עם מישהו שאין לו כלל תוכנת GIS - רק Google Earth - בניגוד לנתונים העשירים והמובנים יותר ש-LandXML או CityGML נושאים.
זהו הגשר המעשי בין נתוני site-survey לכלי תכנון אזרחי כמו Civil 3D, ועושה עבור שטח ויישורים בערך מה ש-IFC עושה עבור אלמנטי מבנה.
מתוחזק על ידי האגודה האמריקאית לפוטוגרמטריה וחישה מרחוק, LAS הוא הפורמט שרוב נתוני ה-LiDAR של סקר שטח וטופוגרפיה מגיעים בו לפני שהם מוכנסים לכלי BIM או תכנון אזרחי - E57 מכסה שטח דומה בעיקר עבור סריקת לייזר קרקעית.
פותחה על ידי מכון ה-Lean Construction, היא עובדת אחורה מתאריכי אבני דרך לתוכניות עבודה שבועיות שמנהלי עבודה וקבלני משנה באמת מתחייבים אליהן, ואז עוקבת אחר מדד "אחוז תוכנית שהושלמה" כדי לתפוס מחויבויות לא אמינות מוקדם במקום לגלות לוח זמנים שהחליק בסוף.
הארגון שממונה על ידי ה-Appointing Party להוביל את מסירת הפרויקט - לעיתים קרובות המתכנן הראשי או הקבלן הראשי, תלוי במסלול ההתקשרות. Lead Appointed Party אחראי על הפקת ה-BEP בתגובה ל-EIR של הלקוח, ועל תיאום עבודת כל Task Teams שהוא ממנה מתחתיו.
בפרויקט מובל-תכנון טיפוסי התפקיד הזה בדרך כלל יושב אצל האדריכל או היועץ הראשי; בפרויקט תכנון-וביצוע או מובל-קבלן הוא לעיתים קרובות יותר יושב אצל הקבלן הראשי - המונח עצמו נייטרלי במכוון ביחס למסלול ההתקשרות, וזו בדיוק הסיבה ש-ISO 19650 משתמש בו במקום בתואר תפקיד ספציפי יותר.
טכניקות כמו Last Planner System ו-target value design שתיהן יוצאות מתנועת ה-lean construction, שמנסחת מחדש "בזבוז" ככל דבר שלא מוסיף ערך ללקוח - עבודה חוזרת, המתנה ומסירות לא אמינות בין קבלנים, לא רק חומר עודף.
Leadership in Energy and Environmental Design
מערכת דירוג בנייה ירוקה מבוססת-נקודות (מהמועצה האמריקאית לבנייה ירוקה) שמסמיכה פרויקט על פני קטגוריות כמו ביצועי אנרגיה, שימוש במים, חומרים ואיכות אוויר פנימי, ומעניקה רמה מ-Certified ועד Platinum. LEED לא דורש BIM, אך בפועל BIM הופך את המרדף אחריו לקל בהרבה: ניתוח אנרגיה, מחקרי אור יום וכמויות חומרים שתיעוד LEED דורש ניתנים לשליפה או לסימולציה ישירות מהמודל במקום חישוב ידני.
זה בעצם מה ש-6D BIM נועד עבורו בפועל - LEED (או המקבילים האזוריים שלו כמו BREEAM) הוא לרוב היעד האמיתי שניתוח האנרגיה והסביבה של 6D נעשה כדי לספק.
תצוגת מקרא ניתנת למיקום על מספר גיליונות בו-זמנית (בשונה מכמעט כל סוג תצוגה אחר), מה שהופך אותה לדרך הסטנדרטית לבנות מקרא דלתות/חלונות, מקרא סוגי קירות, או מקרא סמלים שצריך לחזור באופן זהה לאורך כל סט השרטוטים.
הוא קיים אך ורק עבור תצוגת המקרא שמציגה אותו - הצבת כיסא כרכיב מקרא לא מוסיפה כיסא אמיתי בשום מקום אחר במודל או בשום טבלה.
סריקת לייזר גולמית לא מגיעה מוכנה לשימוש - Cyclone הוא המקום שבו כמה סריקות בודדות מיושרות לענן נקודות אחד נקי ורשום, לפני שהוא מיוצא ל-E57 או מוכנס לתהליך scan-to-BIM.
זהו המסמך שהכי נפוץ לדלג עליו ברשימה הזו - כולם מסכימים שהוא בעל ערך, ועדיין הוא הדבר הראשון שנופל כשצוות פרויקט עובר ישר לעבודה הבאה.
הוא מאפשר לרכש ארוך-טווח או לעבודת אתר מוקדמת להתחיל בלי לחכות שכל סעיף בחוזה יסוכם - שימושי לשמירה על התקדמות לוח הזמנים, אך מסוכן אם משתמשים בו כדי להימנע מהסכמה על תנאים במקום לזרז דברים באמת.
מפלסים (Levels) הם אחד הדברים הראשונים שמוגדרים בכל פרויקט רוויט, וכמעט כל דבר אחר תלוי בהם: Worksets, שלביות (Phasing), טבלאות ומיקום משפחות - כולם מתייחסים למפלס, במישרין או בעקיפין. הגדרת מפלסים לא נכונה בשלב מוקדם היא אחת הסיבות הנפוצות ביותר לעבודה חוזרת מתסכלת בהמשך.
הערכת מחזור חיים (LCA)
LCA היא מסגרת החישוב עצמה (מוגדרת בתקנים כמו EN 15978), בעוד פחמן גלום ופחמן לאורך מחזור חיים הם המספרים הספציפיים שהיא מפיקה - הכמויות ושיוכי החומרים של מודל רוויט הם מה שבפועל מזין כלי LCA, מה שהופך הזנת נתוני חומרים מדויקת למשימת קיימות ולא רק משימת תיעוד.
קו החתך של קיר צריך להיראות עבה יותר מקו נסתר מאחוריו בכל קנה מידה שבו שרטוט עשוי להדפס - משקלי קו הם מה ששומרים על ההיררכיה הגרפית הזו עקבית לאורך כל סט הגיליונות במקום שתותאם תצוגה אחר תצוגה.
Revit Links
המנגנון להביא מודל שלם ונפרד - קובץ Revit של דיסציפלינה אחרת, סקר שטח, מודל של יועץ - לתוך פרויקט כהפניה חיה, בלי למזג את הנתונים בפועל יחד. בניגוד לWorksets, שמחלקים בעלות בתוך מודל מרכזי משותף אחד, מודלים מקושרים הם קבצים נפרדים לגמרי: האדריכל מקשר את מודל מהנדס הקונסטרוקציה כדי לתאם מולו, אך כל צוות עדיין הבעלים ועורך את הקובץ שלו בעצמאות.
מיקום נכון של קישורים תלוי לחלוטין בהגדרה נכונה של קואורדינטות משותפות - קישור עם מערכת קואורדינטות שגויה ייראה תקין בבידוד ויהיה מוזז במטרים ברגע שמביאים אותו למודל המארח.
פיצויים מוסכמים הם ההשתקפות הפיננסית של הארכת זמן - אם עיכוב הוא אשמת הקבלן, הפיצויים מתחילים להצטבר; אם EOT תקף מוענק במקום זאת, תאריך ההשלמה עצמו זז והפיצויים לא חלים, וזו בדיוק הסיבה שתיעוד לוח הזמנים והשינויים הבסיסי חשוב כל כך לשני הצדדים.
רמת דיוק
מוגדר על ידי המכון האמריקאי לתיעוד בנייה, רמת הדיוק (LOA) מדרגת נתוני תפיסת מציאות (כמו תוצרי Scan-to-BIM) לפי טולרנס נמדד - עד כמה הגאומטריה של המודל קרובה למציאות ה-as-built - וזו שאלה שונה לגמרי מ"כמה מידע האלמנט הזה נושא" של רמת הפיתוח (LOD). אלמנט מפורט מאוד יכול עדיין להיות בעל דיוק מיקום נמוך, ולהפך.
מודל קונסטרוקטיבי לעיתים רחוקות נכשל תחת סוג עומס בודד לבדו - התרחישים המסוכנים הם שילובים, כמו עומס רוח שיא שחופף עם עומס חי מלא מאיכלוס - וזו בדיוק הסיבה שקודי בנייה מחייבים בדיקת עשרות שילובי עומסים ספציפיים ולא כל סוג עומס בבידוד, תהליך שזרימות עבודה מודרניות של רוויט-ל-Robot יכולות לאוטומט.
כל חבר צוות בפרויקט משותף עובד בתוך קובץ מקומי משלו במקום ישירות מהמודל המרכזי המשותף - זה שומר על הקובץ מהיר לתגובה ומאפשר לכל אחד לערוך את ה-Worksets שלו בלי לחכות לאחרים, תוך סנכרון שינויים הלוך ושוב דרך Synchronize with Central.
Level of Development
LOD מגדיר עד כמה מפורט ואמין אלמנט במודל ה-BIM בשלב נתון. הוא עונה על השאלה: "כמה אני יכול לסמוך על אלמנט מודל זה, ואיזה מידע הוא מכיל?"
סולם ה-LOD הסטנדרטי נע בין 100 ל-500:
| LOD | שלב | משמעות |
|---|---|---|
| 100 | קונספט | האלמנט קיים כסמל או מסה. גודל ומיקום משוערים. |
| 200 | תכנון סכמטי | אלמנט גנרי עם גיאומטריה וגודל משוערים. |
| 300 | פיתוח תכנון | גיאומטריה ספציפית, מידות מדויקות, מיקום וכיוון. |
| 350 | מסמכי בנייה | כולל חיבורים לאלמנטים סמוכים. מוכן לתיאום. |
| 400 | ייצור | מפורט דיו לייצור ולהרכבה. |
| 500 | כפי שנבנה | מאומת בשטח. מייצג את המבנה כפי שנבנה בפועל. |
LOD משמש ב-BEP לציון איזו רמה כל אלמנט מודל חייב להגיע אליה בכל אבן דרך של הפרויקט.
סרגל LOD 100–500
LOD 100 ייצוג סכמטי כללי - נפח או סמל גנרי
LOD 200 גיאומטריה מקורבת - מידה, צורה ומיקום גסים
LOD 300 גיאומטריה מדויקת - מידה, צורה, מיקום וכמות סופיים
LOD 350 כמו 300, בתוספת ממשקים מול מערכות בניין אחרות
LOD 400 מוכן לייצור - מפורט לביצוע והתקנה
LOD 500 כפי-שנבנה (As-Built) - מאומת בשטח
Level of Information
לרוב מזווג עם LOD. בעוד LOD מתאר פירוט גיאומטרי, LOI מתאר את הנתונים הלא-גרפיים המצורפים לאלמנט - מאפיינים, מפרטים, נתוני חומר, ערכי ביצועים.
דלת ב-LOD 300 מכילה גיאומטריה מדויקת. אותה דלת עם LOI גבוה מכילה גם דירוג אש, דירוג אקוסטי, מפרט חומרה וקוד מוצר של היצרן. שני הממדים חשובים למסירה ולניהול המתקן.
Level of Information Need
המונח החדש יותר מעידן ISO 19650, שמחליף בהדרגה את צמד LOD/LOI במפרטים. LOIN הופך את השאלה: במקום "לאיזה LOD האלמנט צריך להגיע?", הוא שואל מי צריך איזה מידע, לאיזו מטרה ובאיזו אבן דרך - ודורש בדיוק את זה, לא יותר.
LOIN מוגדר בתקן האירופי EN 17412-1 ומכסה שלושה סוגי תוכן:
המטרה היא להפסיק מידול-יתר: מידע שאף אחד לא ביקש עולה זמן וכסף לייצר ולתחזק.
לעומת Enscape או Twinmotion, Lumion משמש לרוב יותר לתמונות סופיות ברמת שיווק ואנימציות מאשר לסיורי סקירת תכנון חיים - זרימת עבודה נפוצה היא מידול ברוויט ולאחר מכן ייצוא ל-Lumion ספציפית עבור הרינדורים המלוטשים שהצגה ללקוח דורשת.
מידע ראשי הוא מה ששומר על מספר חדר או תגית נכס עקביים לאורך מודל ה-BIM, ה-CDE, מערכת ה-FM וכל טבלה שנגזרת מהם. בלי מקור ברור למידע ראשי, אותו נכס מסתיים עם שלושה מזהים שונים במקצת בשלושה מקומות שונים - בדיוק חוסר העקביות ש"מקור אמת יחיד" אמור למנוע.
המקבילה הצפון-אמריקאית ל-Uniclass - MasterFormat (מפורסם על ידי CSI, מכון המפרטים לבנייה) מארגן מידע בנייה לחטיבות ממוספרות, כמו חטיבה 08 לפתחים או חטיבה 23 למיזוג אוויר. זהו בעיקר תקן לכתיבת מפרטים ולא מערכת סיווג BIM מלאה, אך הוא מופיע כל הזמן בפרויקטים אמריקאים וקנדיים כעמוד השדרה לארגון פרקי המפרט, ומספרי החטיבות שלו לרוב ממופים לפרמטרים במודל לצורך עקביות בין השרטוטים למפרטים.
היכן ש-Uniclass שולט בפרויקטים בריטיים/בינלאומיים, MasterFormat הוא מה שתפגשו בפרויקטים צפון-אמריקאים.
במבנה גדול שבו קומה אחת לא נכנסת לגיליון בודד בקנה מידה שמיש, זהו הסימון ששומר על מישהו שקורא גיליון 3 מלהתבלבל לגבי איפה גיליון 4 ממשיך.
זה מה שהופך פירוק מרעיון מקווה לרעיון מעשי - צוות הריסה לא יכול בקלות לעשות שימוש חוזר בקורה שאף אחד לא באמת תיעד את דירוג החומר וההיסטוריה שלה.
בעוד שטבלת דלתות סופרת דלתות, כתב כמויות חומרים יכול לדווח על השטח הכולל של גימור צבע ספציפי בכל חדר שמשתמש בו - ומזין ישירות כתב כמויות ללא מעבר מדידה ידני נפרד.
לעומת סורק לייזר ברמת מדידה מקצועית, מצלמת Matterport מהירה וזולה יותר להפעלה אך פחות מדויקת - זרימת עבודה נפוצה בפרויקטי שיפוץ קטנים היא סריקת Matterport מהירה לסיור חזותי ומדידות גסות, ושמירת סריקת לייזר מלאה למה שדורש דיוק מידול as-built אמיתי.
מחבר אלמנט המודל
בפרויקט רב-דיסציפלינרי ומתואם, לא תמיד ברור מי "הבעלים" של קיר או תעלה מסוימים במודל המאוחד - סימון מחבר אלמנט המודל (Model Element Author, לרוב קוד או ראשי תיבות על האלמנט עצמו) מסיר את אי-הבהירות, ומקשר כל אלמנט חזרה לצוות המשימה הספציפי האחראי לגאומטריה ולנתונים שלו.
זהו הפחות פורמלי מבין שלושת מסלולי הסכסוך המרכזיים - זול ומהיר יותר מבוררות דין (adjudication) או בוררות (arbitration), אך עובד רק אם שני הצדדים באמת רוצים להגיע להסכמה ולא לנצח בוויכוח.
Mechanical, Electrical & Plumbing
תחומי ההנדסה שמטפלים בשירותי המבנה: מערכות מיזוג אוויר, חלוקת חשמל, אינסטלציה, הגנה מפני אש ועוד. מודלי MEP הם מהמורכבים ביותר בתהליך BIM מאוחד מכיוון שהמערכות שהם מכילים חייבות להיות מתואמות כנגד הקונסטרוקציה וכנגד עצמן.
ב-Revit, עבודת MEP מתבצעת ב-Revit MEP - תצורה ספציפית לדיסציפלינה של אותה פלטפורמה שמשמשת אדריכלים ומהנדסי קונסטרוקציה.
הגאומטריה של משפחת דלת היא מידע; העובדה שהיא עודכנה לאחרונה בתאריך מסוים, על ידי אדם מסוים, מתויגת בקוד Uniclass מסוים, היא מטא-דאטה - בדיוק מה ש-audit trail של CDE ומילון נתונים מנהלים.
בעוד שלוח זמנים (כמו רצף 4D) קובע מתי העבודה מתבצעת, הצהרת שיטת עבודה מסבירה כיצד - השלבים בפועל, הציוד ואמצעי הבטיחות שצוות יעקוב אחריהם למשימה כמו הרמת מנוף או יציקת בטון, ולעיתים קרובות נבדקת לצד המודל כדי לוודא שהרצף אכן ניתן לביצוע פיזית.
בעוד שכלי Autodesk שולטים בעולם המבנים, MicroStation של Bentley ויישומי ה-OpenX שלה (OpenRoads, OpenBridge) נפוצים במיוחד בתשתיות אזרחיות - שתי המערכות נפגשות באותו פרויקט דרך החלפת IFC ולא דרך אחת שמחליפה את השנייה.
Information Delivery Plans
שני מסמכים מעולם ISO 19650 שחיים לצד ה-BEP. TIDP (Task Information Delivery Plan) הוא תוכנית המסירה של צוות בודד: אילו קבצים ומודלים הצוות מספק, מתי ובאיזו רמת מידע. MIDP (Master Information Delivery Plan) מאחד את כל ה-TIDP-ים לתוכנית מסירה אחת של הפרויקט כולו - לוח הזמנים של המידע, לא של הבנייה.
אם ה-EIR אומר "מה", ה-MIDP אומר "מי ומתי".
Revit, ArchiCAD ו-Tekla Structures הם כלי יצירה; Navisworks ו-Solibri אינם כאלה - הם מאחדים ובודקים את מה שכלי היצירה כבר בנו. הבנת הקטגוריה שאליה שייכת תוכנה מסוימת מסבירה מדוע דוח התנגשויות מ-Navisworks עדיין חייב להיות מתוקן חזרה במודל היוצר, ולא ב-Navisworks עצמו.
התהליך המתמשך והמחזורי שזיהוי התנגשויות הוא רק חלק ממנו: איחוד סדיר של מודלי הדיסציפלינות למודל מאוחד, סקירתו (ויזואלית ודרך בדיקות אוטומטיות), רישום כל בעיה שנמצאה כבעיה במעקב, הקצאתה למי שצריך לתקן אותה, ואישור התיקון במחזור הבא. הרצת זיהוי התנגשויות בודדת היא תמונת מצב; תיאום מודלים הוא הקצב השבועי או הדו-שבועי החוזר שגורם למודלי הפרויקט להתכנס לעבר תכנון בר-בנייה וללא קונפליקטים במקום להתרחק יותר.
בעיות בדרך כלל נעקבות עם קובצי BCF כך שכל צוות יכול לפתוח בדיוק את אותה בעיה בתוכנה שלו, בזווית המצלמה והאלמנט המדויקים שבהם היא נמצאה.
קירות, דלתות, תעלות וחדרים - כולם אלמנטים במודל (Model Element) - אבני הבניין הבסיסיות הנושאות גם גאומטריה וגם נתונים בתוך מודל מידע. הבנת "אלמנט מודל" כיחידה הגנרית היא מה שהופך מושגים כמו רמת פיתוח ומחבר אלמנט מודל למשמעותיים, שכן שניהם מוגדרים לפי אלמנט ולא לפי מודל שלם.
בשונה ממשפחה (Family), שהיא רכיב בודד לשימוש חוזר, קבוצה (Group) מאגדת מספר אלמנטים קיימים (למשל, קירות, דלת וריהוט של חדר מלון) ליחידה אחת שניתן למקם - עריכת מופע אחד של הקבוצה יכולה להתפשט לכל העותקים, מה שהופך אותה לדרך מהירה לחזור על פריסות זהות לאורך קומה או מגדל שלם.
מודל יכול להיות מתוכנן בצורה מבריקה ועדיין לא בריא - מאות אזהרות לא פתורות, מנופח משנים של משפחות לא מנוקות, איטי להיפתח לכל מי שבצוות. מעברי audit ו-purge סדירים הם התחזוקה השוטפת שהוא באמת תלוי בה.
קו מודל שמצויר בתוכנית אתר כדי לסמן גבול מגרש מופיע גם בתצוגה תלת-ממדית וגם בחתך, מכיוון שהוא גאומטריית מודל אמיתית - קו פרט שמבצע את אותה משימה יופיע רק באותה תצוגת תוכנית בודדת.
היא בדרך כלל מופעלת אוטומטית דרך תוכנת בדיקת כללים (Solibri, Navisworks, או בדיקת IDS מותאמת אישית) ולא ידנית, ותופסת דברים כמו פרמטרים חסרים או אלמנטים בוורקסט הלא נכון לפני שהם מגיעים למודל מאוחד וגורמים לבעיה יקרה בהרבה בהמשך.
זוהי התוצאה המעשית ששמאי כמויות שואפים אליה כשהם דוחפים למודלים מובנים היטב ומתאימי-LOD - ככל שהכמויות של מודל אמינות יותר, כך אומדן זקוק לפחות מדידה חוזרת ידנית.
בנייה מודולרית ו-DfMA הן שתי גישות ספציפיות שנמצאות תחת מונח-העל הרחב הזה - MMC הוא הקטגוריה שממשלת בריטניה והתעשייה בפועל משתמשים בה כשדנים במעבר משיטות בנייה מסורתיות בכללותו.
שיטת בנייה שבה קטעים גדולים של מבנה - חדרים שלמים, תאי אמבטיה, מודולים קונסטרוקטיביים - מיוצרים במלואם במפעל ומובלים לאתר להרכבה, במקום להיבנות חתיכה-חתיכה באתר. זה הקצה הפיזי והגדול-בקנה-מידה של הספקטרום של DfMA: במקום רכיבים טרומיים בודדים, נפחים שלמים של המבנה מגיעים מוכנים או כמעט מוכנים.
BIM קרוב להיות תנאי מוקדם לבנייה מודולרית בכל קנה מידה אמיתי: המפעל צריך דיוק מודל ברמת ייצור LOD 400 כדי לייצר מודולים שבאמת יתאימו יחד נכון באתר, מכיוון שיש מעט מקום "להבין את זה" ברגע שמודול כבר עזב את המפעל.
הגדרת תצוגת מודל
סכימת ה-IFC המלאה עצומה - הגדרת תצוגת מודל (MVD) מצמצמת אותה בדיוק למה שנדרש לתהליך עבודה אחד, כמו Coordination View לגילוי התנגשויות או Quantity Take-off View לכימות כמויות, כך שספקי תוכנה יכולים להסמיך תמיכה בתת-קבוצה ספציפית וניתנת לבדיקה במקום בכל ה-IFC בבת אחת. buildingSMART מתחזקת את ה-MVD הרשמיים לצד תקן ה-IFC עצמו.
Autodesk Navisworks
הכלי הייעודי של Autodesk לסקירת מודלי BIM גדולים ומאוחדים ממספר דיסציפלינות וחבילות תוכנה בו-זמנית. Navisworks מאגד מודלים (Revit, IFC, DWG ועוד) לתצוגה מאוחדת קלילה אחת, מריץ זיהוי התנגשויות, מניע תזמון בנייה 4D, ומנהל בעיות תיאום, לעיתים קרובות מוחלפות כקובצי BCF עם צוות התכנון.
זה לא כלי מידול - שום דבר לא מתוכנן ב-Navisworks - זה המקום שבו תיאום ותכנון ביצוע קורים ברגע שמודלי הדיסציפלינות קיימים. בהרבה פרויקטים בהובלת קבלן, Navisworks (או מתחרה כמו Solibri) הוא המקום שבו פגישת התיאום "האמיתית" באמת מתקיימת.
המפרט הלאומי לבנייה
מפרטי NBS הם באופן מסורתי המסמך הכתוב המפורט שנמצא לצד השרטוטים והמודל, ומפרט בדיוק איזה מוצר, תקן ביצוע או איכות עבודה נדרשים לכל אלמנט. כלי NBS מודרניים (כמו NBS Chorus) מקשרים את הטקסט הזה ישירות לאובייקטים ב-BIM לפי קוד מיון, כך ששינוי בסעיף מפרט ניתן לעקוב אחריו ישירות לאלמנטים במודל שהוא חל עליהם.
הודעות אזהרה מוקדמת ואירועי פיצוי הם שני המנגנונים המזוהים שלו - כל החוזה מתוכנן סביב העלאת בעיות בזמן שהן עדיין קטנות וזולות לתיקון.
משפחה שטעונה בתוך משפחה אחרת - ידית שמקוננת בתוך משפחת דלת, ציר שמקונן בתוך משפחת חלון - שמאפשרת לבנות רכיבים מורכבים מחתיכות קטנות יותר וניתנות לתחזוקה עצמאית במקום גוש גיאומטריה מונוליטי אחד. משפחת ההורה יכולה לחשוף (או "לשתף") את הפרמטרים של המשפחה המקוננת כך שהם עדיין מופיעים ומתוזמנים נכון ברמת הפרויקט.
קינון הוא מה שהופך משפחות גדולות וריאליסטיות לניתנות לניהול באמת: עדכנו את משפחת הידית פעם אחת, וכל משפחת דלת שמקננת אותה קולטת את השינוי, במקום שארבעים ידיות נפרדות יצטרכו למידול ידני מחדש.
Net Zero Carbon
יעד שבו פליטות הפחמן של מבנה - הן מהתפעול שלו (צריכת אנרגיה) והן מהבנייה שלו (פחמן גלום) - מצומצמות עד כמה שמעשית אפשרי, כשכל שארית בלתי נמנעת מאוזנת דרך קיזוזים או הסרת פחמן, כך שהתרומה נטו לפחמן האטמוספרי היא אפס. "Net Zero פחמן תפעולי" ו"Net Zero פחמן כל-חיים" הן טענות שונות באופן משמעותי, צרות ורחבות יותר, וההבחנה חשובה כשלקוח מבקש ספציפית אחת מהן.
תפקיד ה-BIM הוא בעיקר בחלק "לצמצם עד כמה שאפשר": ניתוח אנרגיה 6D וחישוב פחמן גלום מכמויות המודל הם מה שנותנים לצוות תכנון לבחון בפועל עד כמה תכנון קרוב ל-Net Zero, הרבה לפני שהבנייה מתחילה.
במקום לחפש בשרשורי אימייל כדי למצוא מי ענה על RFI ספציפי, Newforma מאנדקסת את כל התקשורת בפרויקט במקום אחד הניתן לחיפוש - שכבת זרימת עבודה שיושבת לצד כלי ה-BIM עצמם, לא בתוכם.
הגאומטריה התלת-ממדית של דלת כמעט ולא אומרת כלום שימושי לניהול מתקנים או לתמחור כשלעצמה; הנתונים הלא-גאומטריים שלה - דירוג אש, סט אביזרים, ספק, תקופת אחריות - הם מה שבאמת נעשה בו שימוש בהמשך על ידי טבלאות, ייצוא COBie ומערכות ניהול מתקנים. הערך האמיתי של BIM מעבר למידול תלת-ממדי פשוט מגיע כמעט כולו מהשכבה הזו.
אדריכל שממונה ישירות על ידי הלקוח בשלב התכנון המוקדם יכול "לעבור המחאה" לקבלן ברגע שהביצוע מתחיל - אותו משרד ממשיך לעבוד על אותו מודל, אך יחסי הלקוח וקו הדיווח שלו מתחלפים משפטית, מה שיכול לשנות בשקט אילו דרישות מידע בפועל מקבלות עדיפות.
זה מה שבאמת הופך נובציה ב-design-and-build למשהו אמיתי - בלי הסכם נובציה חתום, היועץ עדיין עונה טכנית רק ללקוח המקורי.
New Rules of Measurement
סדרת תקנים (מ-RICS, מכון הסוקרים המוסמכים המלכותי) שמגדירה בדיוק איך למדוד ולתמחר עבודות בנייה בעקביות, על פני שלושה כרכים המכסים תכנון עלויות, מדידה מפורטת ועלויות תחזוקה. NRM הוא ספר הכללים שהופך את QTO וה-5D למשמעותיים בפועל - הוא מגדיר מה בעצם נחשב "יחידה אחת" של קיר, דלת או חפירה, כך שכמויות שהופקו ממודל BIM ניתנות להשוואה ותמחור בעקביות בין פרויקטים ובין כמאים.
בלי תקן מדידה כמו NRM מאחוריו, חישוב כמויות שמופק ממודל הוא סתם מספר - NRM הוא מה שהופך אותו למספר אמין.
מדריך תפעול ותחזוקה
באופן מסורתי הר של קבצי PDF שנמסר בקופסה בסוף פרויקט, תוכן מדריך התפעול והתחזוקה נשאב יותר ויותר ישירות מנתוני מודל BIM - לוחות תחזוקה, תקופות אחריות, רשימות חלפים - כך שמנהלי מתקנים מקבלים מידע מובנה וניתן לחיפוש במקום ארון תיוק לחפור בו.
זהו אחד הפורמטים התלת-ממדיים העתיקים והנתמכים ביותר, וזו בדיוק הסיבה שהוא עדיין משמש להעברת גאומטריית רשת פשוטה לכלי רינדור, מנועי משחק או תהליכי הדפסה תלת-ממדית, שם FBX או glTF עשויים לשאת יותר ממה שנדרש.
BS 8541-1 הוא בדיוק סוג הסטנדרט שספריית אובייקטים מנוהלת היטב בנויה לפיו - בלעדיו, ספרייה הופכת לתיקיית קבצים עם שמות לא עקביים שאף אחד לא סומך עליהם מספיק כדי להשתמש בהם שוב.
זוהי השכבה הבסיסית שמתחת לעקיפות visibility/graphics ולתבניות תצוגה - שינוי משקל קו של קטגוריה ב-Object Styles מעדכן אותו בכל מקום כברירת מחדל, אלא אם תצוגה ספציפית כבר עקפה אותו.
קו CAD שמייצג קיר הוא רק גאומטריה; אובייקט קיר ב-BIM יודע את הסוג שלו, דירוג האש והעלות שלו - ומתעדכן בכל תוכנית, חתך וטבלה בבת אחת כשהוא משתנה.
Organizational Information Requirements
פסגת פירמידת הדרישות של ISO 19650. OIR מתאר את המידע שארגון שלם צריך כדי לקבל החלטות אסטרטגיות ותפעוליות על פני כל תיק הנכסים שלו - לא רק מבנה אחד. חשבו עליו כ"למה" שמאחורי כל השאר: ה-OIR מעצב את ה-AIR (מה שנכס ספציפי צריך), שמעצב את ה-EIR (מה שפרויקט ספציפי צריך).
רוב צוותי הפרויקט הבודדים אף פעם לא נוגעים ב-OIR ישירות - הוא חי ברמת ניהול תיק הנכסים של ארגון הלקוח - אך שווה לדעת שהוא קיים, כי הוא מסביר למה חלק מדרישות המידע בפרויקט יכולות להרגיש מנותקות מהיקף הפרויקט עצמו.
מערכת מיון בנייה OmniClass
OmniClass בנוי מ-15 טבלאות ממוספרות (טבלה 21 לאלמנטים, טבלה 23 למוצרים, טבלה 33 לתחומי עיסוק וכן הלאה), וכל אחת מהן ניתנת לשימוש עצמאי או בשילוב כדי למיין אובייקט בודד ממספר זוויות בו-זמנית. זו מערכת המיון שהכי נפוץ לשלב עם MasterFormat, והיא מוזכרת בתבניות משפחות ובקבצי Keynote ברוויט לפרויקטים בצפון אמריקה.
openBIM / closedBIM
שתי גישות לשיתוף מידע. openBIM נשען על פורמטים פתוחים וניטרליים - IFC, BCF, IDS - כך שכל צד בפרויקט יכול לעבוד בתוכנה שהוא בוחר, והמידע לא כלוא אצל ספק אחד. closedBIM מניח שכולם עובדים באותו אקוסיסטם (למשל "כולם ב-Revit"), מה שמפשט את התיאום היומיומי אבל יוצר תלות בספק ומקשה על מסירה ארוכת טווח.
בפרויקטים ציבוריים הדרישה לתוצרי openBIM הולכת וגוברת.
נפוצה בבתי חולים ותשתיות גדולות, היא מכסה הכשרת צוות, לוגיסטיקת מעבר ובדיקת מערכות בתנאי תפעול אמיתיים - ההרחבה המעשית של soft landings מעבר לקו הסיום של הביצוע.
היא מתעדכנת אוטומטית ככל שמעגלים חשמליים מתווספים או משתנים - חשמלאי באתר סומך על דיוקה הרבה יותר מאשר על תצוגת התוכנית עצמה.
מדרגות שתוכננו פרמטרית ומוגדרות לפי "עלייה כוללת חלקי גובה מדרגה" מחשבות מחדש את מספר המדרגות ברגע שגובה הקומה משתנה. Grasshopper ו-Dynamo קיימים כדי לקחת את הרעיון הזה רחוק יותר ממה שהפרמטרים של משפחה בודדת מאפשרים.
Parametric Modeling
המונח שמסביר למה Revit הוא לא "אוטוקאד בתלת-ממד". במידול פרמטרי כל אלמנט מוגדר על ידי פרמטרים - מידות, חומרים, כללים ויחסים - ולא על ידי קווים קפואים. שינוי פרמטר אחד מעדכן את האלמנט ואת כל מה שתלוי בו: מזיזים קיר - הדלתות, המידות והכמויות מתעדכנות איתו.
זה מה שמאפשר ל-BIM להיות מודל חכם ולא רק ציור: הגיאומטריה והנתונים קשורים זה לזה, והמודל שומר על עקביות בכל שינוי.
זהו קרוב קל-משקל יותר של הסכם מסגרת מלא - פחות פורמלי, אך בנוי על אותו היגיון שלפיו שיתוף פעולה חוזר מנצח מכרז תחרותי חד-פעמי עבור סוגים מסוימים של עבודה מתמשכת.
הוא חייב להיות קיים לפני שעבודות חפירה או קיר מסוימות מתחילות - דילוג עליו הוא מקור נפוץ ובלתי נמנע לחלוטין לסכסוכי שכנים ולעיכוב תחילת עבודה באתר.
PAS 128: מפרט לגילוי, אימות ואיתור תשתיות תת-קרקעיות
PAS 128 מגדיר רמות איכות (מ-D ועד A, כאשר A היא הוודאית ביותר) לנתוני סקר תשתיות, כך שמודל שמציג קו גז קיים יכול לשאת דירוג ביטחון מפורש - קריטי לפני שמתחילים חפירה או עבודות יסודות ליד תשתיות שאיש לא אימת פיזית.
Publicly Available Specification 1192
סדרת PAS 1192 (שפרסם BSI, מכון התקנים הבריטי) הייתה סדרת המפרטים הלאומית הבריטית לניהול מידע BIM לפני שהתקן ISO 19650 נכתב. PAS 1192-2 כיסה את שלב הביצוע וההקמה, PAS 1192-3 כיסה את ניהול הנכס התפעולי, ו-PAS 1192-5 כיסה BIM מודע-אבטחה.
ISO 19650 נבנה ישירות על גבי PAS 1192 - אזורי ה-CDE (WIP, Shared, Published, Archive), הצמד EIR/BEP, וחלק ניכר מהמינוח עברו כמעט ללא שינוי. אם אתם קוראים מפרט BIM בריטי ישן יותר, סביר שהוא עדיין מפנה ל-PAS 1192 בשמו.
תקן Passivhaus (בית פסיבי)
בשונה מ-LEED או BREEAM, שמעניקים נקודות בהרבה קטגוריות, Passivhaus מסמיך בניין מול קבוצה קטנה של ספי ביצוע מדידים ונוקשים - בעיקר דרישת חימום/קירור ואטימות אוויר (הנמדדת במבחן Blower Door). מכיוון שהתקן רגיש כל כך לפרטי הביצוע, פרויקטי Passivhaus דורשים בדרך כלל תיאום הדוק יותר בין מודל הרוויט לבין המעטפת בפועל, לעומת הסמכת בנייה ירוקה טיפוסית.
אחוז ההשלמה שמצוין בתעודת תשלום נבדק יותר ויותר מול כמויות אמיתיות שנשלפות מהמודל עצמו (דרך QTO או כלי כמו Assemble) ולא מהאומדן של הקבלן עצמו, מה שהופך מודל מדויק ומעודכן לקלט ישיר בתזרים המזומנים של הפרויקט.
ערבות ביצוע מגנה על הלקוח מפני כישלון מוחלט של הקבלן או חדלות פירעון, שהוא סיכון שונה מכספי עיכבון (הגנה מפני ליקויים בעבודה שהושלמה ברובה) או פיצויים מוסכמים (פיצוי על איחור) - שלושת המנגנונים קיימים לעיתים קרובות באותו חוזה, כל אחד מכסה מצב כישלון אחר.
phasing קובע לאיזה שלב אלמנט שייך; מסנן השלב הוא מה שבפועל מחליט כיצד תצוגה ספציפית בוחרת להציג עבודה קיימת, הרוסה וחדשה ביחס להקצאה הזו.
המערכת של Revit למידול מבנה לאורך זמן ולא כתמונת מצב סטטית אחת. לכל אלמנט מוקצה Phase Created (שלב יצירה) ואם רלוונטי גם Phase Demolished (שלב הריסה), וכל תצוגה מוגדרת להציג שלב ספציפי (או השוואת שלבים, כמו "בנייה חדשה" שמציגה עבודה חדשה מודגשת מול מבנה קיים מוצלל). זה חיוני לפרויקטי שיפוץ וחיזוק: אותו מודל יכול לייצג מצב קיים, הריסה ועבודה חדשה בו-זמנית, כאשר כל תצוגה מסננת להציג רק את מה שרלוונטי.
Phase Filters (מסנני שלבים) שולטים בדיוק איך כל מצב שלב מצויר - איזה סגנון קו מקבלים אלמנטים הרוסים, האם אלמנטים קיימים מוצגים בכלל - ונותנים שליטה מלאה על האופן שבו סיפור ציר הזמן של המבנה מסופר על הנייר.
תוכנה מתאימה נקודות משותפות בין עשרות או מאות תמונות חופפות (לרוב שצולמו מרחפן) כדי לשלש קואורדינטות אמיתיות - זולה ומהירה יותר ללכידה מסריקת לייזר עבור אתרים גדולים, אך בדרך כלל פחות מדויקת לפרטים פנימיים צפופים, ולכן שתי השיטות משולבות פעמים רבות באותו פרויקט.
Project Information Model
חצי אחד מהצמד המרכזי של ISO 19650. ה-PIM הוא מודל המידע שנבנה במהלך התכנון והבנייה: מודלים, שרטוטים, מפרטים, לוחות זמנים ותיעוד, שמפותחים ומאושרים דרך ה-CDE.
במסירה, החלקים הרלוונטיים של ה-PIM עוברים לבעלים והופכים לבסיס של ה-AIM.
Project Information Requirements
החבר השלישי במשפחת OIR/AIR/PIR. PIR אוסף את המידע שהלקוח צריך במהלך חיי פרויקט ספציפי אחד - לא כדי לתפעל את הנכס המוגמר (זה ה-AIR) ולא עבור הארגון כולו (זה ה-OIR), אלא כדי לקבל החלטות טובות לגבי העבודה הספציפית הזו: מעקב תקציב, ניהול סיכונים, אישורי תכנון.
בפועל, ה-EIR שצוות הפרויקט מקבל מורכב בדרך כלל משילוב של תוכן AIR ו-PIR רלוונטי - הדרך של הלקוח לומר "הנה כל מה שאני צריך מכם, עבור הפרויקט הזה ועבור הפעלת המבנה לאחר מכן".
הערכות biodiversity net gain והצהרת עיצוב וגישה הן שתיים מהמסמכים התומכים שבקשת תכנון זקוקה להם יותר ויותר לצד השרטוטים עצמם.
Scan to BIM
הגשר בין מבנים קיימים ל-BIM. ענן נקודות (Point Cloud) הוא התוצר של סריקת לייזר תלת-ממדית (או פוטוגרמטריה): מיליוני נקודות מדודות שיחד יוצרות תמונת מצב דיגיטלית מדויקת של חלל פיזי.
Scan to BIM הוא תהליך העבודה של ייבוא ענן הנקודות (ב-Revit: קובצי RCP/RCS, מקושרים כמו כל הפניה אחרת) ומידול המבנה האמיתי מעליו - קירות, רצפות, קונסטרוקציה, מערכות - כדי לקבל מודל as-built מדויק לפרויקטים של שיפוץ, חיזוק או תיעוד.
הערכת שימוש לאחר איכלוס (POE)
הערכת POE משווה את הכוונה "As Designed" מול המציאות "As Occupied" - צריכת אנרגיה בפועל מול התחזית של סימולציית הביצועים, סקרי נוחות למשתמשים, אופן השימוש השונה במרחבים מהמתוכנן - וסוגרת את המעגל ש-Soft Landings ו-BS 8536 שניהם נועדו להקים כבר מההתחלה.
זהו השלב שבין ניהול הצעות מחיר לחתימה בפועל על חוזה - הנקודה שבה שורה עמומה בכתב כמויות בדרך כלל נפתרת.
הנפקת התעודה הזו היא בפועל מה שמתחיל את הספירה של תקופת אחריות הליקויים ומעביר את האחריות התפעולית ללקוח - חבילת המודל והתיעוד שנמסרת סביב אבן דרך זו היא מה שצוות ניהול הנכסים יחיה איתה שנים אחר כך.
זהו החצי של הלקוח בהחלפת המידע של ה-CDM, ומזין ישירות את תוכנית שלב הביצוע של הקבלן עצמו.
תאום דיגיטלי המחובר לחיישני ציוד חיים יכול לסמן משאבה שנכשלת או יחידת מיזוג שמגמתה לקראת תקלה שבועות מראש, ולאפשר לצוותי ניהול הנכסים לתזמן את התיקון בתנאים שלהם במקום להגיב לחירום - התועלת המעשית של השקעה בנתוני BIM מדויקים עבור שלב התפעול.
בעוד BIM 360/ACC ו-Autodesk Forma צמחו ישירות מהצד של תיאום התכנון/המודל באקוסיסטם של Autodesk, Procore היא פלטפורמה שמובילה בניהול בנייה - קבלנים ראשיים רבים מריצים את Procore לתפעול האתר תוך המשך תיאום המודל עצמו דרך כלי BIM נפרד.
היא נקבעת לפני כמעט כל דבר אחר בפרויקט, כי היא קובעת מי בפועל אחראי לסיכון התכנון לאחר שהביצוע מתחיל - החלטה שכל מסמך אחר ברשימה הזו נכתב כדי לשקף אותה.
זהו מנגנון העברת הסיכון הסטנדרטי שמאחורי כמעט כל מינוי יועץ תכנון - לקוח בדרך כלל ידרוש הוכחת כיסוי PI בתוקף לפני חתימה עם מישהו.
מעבר של רחפן או מצלמת 360 מעלה תיעוד של האתר בקצב קבוע, ונתוני לכידת המציאות האלה מושווים מול מודל לוח הזמנים 4D כדי לסמן מה מקדים, בקצב או מפגר - והופך את "איך זה מתקדם שם" לתשובה אובייקטיבית ומבוססת מודל, במקום רושם סובייקטיבי מביקור באתר.
זוהי הצורה הפשוטה והוותיקה ביותר של reality capture בפרויקט - עדיין בעלת ערך גם אחרי שפוטוגרמטריה וענני נקודות הפכו לסטנדרט, כי תמונה מתוארכת היא לפעמים הדרך המהירה ביותר להוכיח מה היה קיים ביום נתון.
הוא נדרש יותר ויותר בפרויקטים ציבוריים בבריטניה ספציפית כדי לתקן מצב כשל ידוע - קבלן משנה שעושה עבודה טובה אך אף פעם לא מקבל תשלום כי הכסף נתקע במקום כלשהו מעליו בשרשרת.
ניהול ערך נצבר ושיטת הנתיב הקריטי הם שתיים מהטכניקות המרכזיות שלה - בקרת פרויקט היא התחום שמפעיל אותן יחד ולא ככלים עצמאיים.
בעוד ש-BEP עונה על "איך המידע ינוהל", תוכנית ביצוע הפרויקט עונה על השאלה הרחבה יותר של איך כל הפרויקט - תקציב, לוח זמנים, תפקידים, סיכון - ינוהל בפועל.
פרמטרי פרויקט הם הפשוטים מבין שלושת סוגי הפרמטרים ברוויט להגדרה - שימושיים לשדה מעקב חד-פעמי רק בפרויקט הזה - אך מכיוון שהם אפויים בתוך אותו קובץ בודד, אי אפשר לתייג אותם, לשלב אותם בטבלאות בפרויקטים אחרים, או לייצא אותם ל-ODBC כפי שניתן עם פרמטר משותף.
הארכת זמן נותנת לקבלן ימים נוספים; עלויות התארכות הן התביעה הנפרדת, ולעיתים קרובות השנויה יותר במחלוקת, על מה שהימים הנוספים האלה בפועל עלו כדי לשמור על האתר פועל.
זוהי אותה פרקטיקה בדיוק כמו snagging תחת שם אחר - שימושי להכיר את שני המונחים, מכיוון שאיזה מהם פרויקט משתמש בו תלוי לעיתים קרובות רק אם הוא עוקב אחר מוסכמות חוזה בריטיות או אמריקאיות.
פקודה מובנית ברוויט שמוצאת ומסירה אלמנטים שטעונים בפרויקט אך לא מונחים בפועל בשום מקום - טיפוסי משפחה לא בשימוש, סגנונות קו, חומרים, View Templates - שבשקט מנפחים את גודל הקובץ ומאטים ביצועים לאורך חיי הפרויקט בלי להוסיף שום ערך.
Purge Unused הוא אחד ההרגלים הפשוטים ובעלי הסיכון הנמוך ביותר לשמירה על מודל בריא: הריצו אותו מדי פעם (בעיקר לפני אבן דרך גדולה או מסירה), ופרויקט שצבר מאות אלמנטים לא בשימוש וחצי-מנוסים במהלך חודשי עבודה נהיה קליל ומהיר יותר באופן ניכר כמעט בלי חיסרון.
בעוד הגרפים החזותיים של Dynamo נגישים למודליסטים בלי רקע בתכנות, pyRevit פונה למשתמשים שכבר יודעים או רוצים ללמוד פייתון - השניים לא סותרים זה את זה, וסטודיואים מסוימים משתמשים ב-Dynamo לגרפים חד-פעמיים מהירים וב-pyRevit לתחזוקת ספרייה משותפת של כלים מותאמים אישית לשימוש חוזר על פני משרד שלם.
הוא קורא וכותב את אותם פורמטים גאומרחביים פתוחים (כמו KML ו-LandXML) כמתחריו המסחריים, מה שהופך אותו לנקודת כניסה נפוצה וזולה לשילוב GIS-BIM.
Quantity Takeoff
הצד המעשי של 5D. QTO הוא הפקת כמויות ישירות מהמודל - שטחי קירות, אורכי תעלות, נפחי בטון, ספירת דלתות - במקום למדוד ידנית מתוכניות. ברוויט זה קורה דרך Schedules; בכלים כמו Navisworks או Power BI אפשר לחתוך את הכמויות לפי קומה, אזור או שלב ביצוע.
האיכות של QTO תלויה ישירות באיכות המידול: אלמנט שמודל לא נכון - יספר לא נכון.
היא מגדירה מי בודק מה, באיזו תדירות, ומול איזה סטנדרט - תוכניות בדיקה ובקרה, בדיקות איכות מודל, ונהלי אישור כולם נמצאים תחתיה. בפרויקט BIM זה בדרך כלל כולל שלבי בדיקת איכות מודל מפורשים לצד הבדיקות הפיזיות המסורתיות.
מודדים כמויות מחלצים כמויות נמדדות משרטוטים או ממודל BIM - בעבר ידנית, וכיום יותר ויותר דרך כלי QTO שקוראים נתוני מודל ישירות - כדי להפיק הערכות עלות, כתבי כמויות והערכות שווי ככל שהפרויקט מתקדם. הנתונים המובנים והפרמטריים של BIM הופכים את המדידה הזו למהירה ופחות רגישה לטעויות בהרבה מעבודה משרטוטים דו-ממדיים בלבד.
המונח המטרייה לכל טכניקה שמשמשת לתיעוד דיגיטלי של המצב הפיזי האמיתי של אתר או מבנה: סריקת לייזר שמפיקה ענן נקודות, צילום רחפנים, תיעוד תצלומי 360 מעלות, ופוטוגרמטריה (בניית גיאומטריה תלת-ממדית מתצלומים חופפים במקום לייזר). Scan to BIM הוא תהליך העבודה הספציפי של הפיכת נתוני Reality Capture למודל Revit שמיש - Reality Capture היא הקטגוריה הרחבה יותר שהתהליך הזה שייך אליה.
בפרויקט שיפוץ, Reality Capture טוב בהתחלה הוא מה שהופך מודל As Built מדויק לאפשרי מאוחר יותר; דילוג עליו בדרך כלל אומר מודל שנבנה על ניחושים ושרטוטים ישנים ולא אמינים במקום.
Autodesk ReCap
פלט הסורק הגולמי בדרך כלל כבד ורועש מדי לעבודה ישירה, כך ש-ReCap מאנדקסת, מנקה ומכווצת אותו לפורמט .rcp/.rcs משלה, לפני שמודליסט מקשר אותו לרוויט כתבנית רקע למעקב אחרי קירות, רצפות ומצב קיים בקנה מידה אמיתי - הצעד המעשי הראשון ברוב תהליכי ה-Scan-to-BIM.
בעוד ש-"as-built" מתאר קטגוריית מידע באופן כללי, שרטוטי התיעוד הם סט המסמכים הדו-ממדי הספציפי שלקוח מקבל בפועל במסירה - ויותר ויותר, הסט הזה נוצר ישירות מהמודל ה-as-built ולא משורטט מחדש מאפס.
מישורי התייחסות הם קווי הנחיה בלתי-נראים בתלת-ממד שמודליסט מוסיף בתוך עורך משפחות או סקיצה (לרוב נעולים עם מידות או פרמטרים) כדי לשמור על יישור הגיאומטריה כשהיא גמישה - הם כלי בזמן סקיצה, בעוד מישור עבודה הוא המשטח התלת-ממדי בפועל שמארח את כל הסקיצה.
היא הפכה למיינסטרים כמעט בן-לילה במהלך המגפה, ונשארה גם אחר כך פשוט כי היא מהירה יותר לבדיקות שגרתיות - סקר רחפן שמזין אותה ישירות עבור כל דבר בגובה או קשה להגעה.
היא יותר ויותר מודלת לצד הפחמן הגלום ופחמן מחזור החיים ולא מטופלת בנפרד - מבנה שתוכנן לתפעול אפס-נטו עדיין זקוק לתוכנית חוסן עבור תנאי האקלים שהוא יתמודד איתם בפועל לאורך חיים של 60 שנה, לא רק אלה הרשומים כיום.
מטריצת אחריות (RACI)
בתהליך עבודה לפי ISO 19650, מטריצת האחריות היא הכלי שבפועל משייך כל פיסת תוכן במודל ותוצר מידע לצוות או תפקיד ספציפי, כך שהתנגשות תיאום או תוצר חסר מקבלים בעלים ברור ומוסכם, במקום "מישהו צריך לתקן את זה" עמום.
עיכבון טיפוסי הוא 5% מכל תשלום, כאשר מחציתו משתחררת בהשלמה המעשית והשאר בסוף תקופת אחריות הליקויים - תמריץ פיננסי אמיתי הקשור ישירות למהירות ולשלמות שבה קבלן סוגר את רשימת הליקויים.
במקום שהלקוח יעכב פיזית 5% מכל תשלום, הבנק או המבטח של הקבלן מנפיק ערבות שמכסה את אותו סיכון - הקבלן שומר על תזרים מזומנים מלא לאורך הפרויקט, והלקוח עדיין יכול לממש את הערבות אם ליקויים נשארים לא מתוקנים בסוף תקופת אחריות הליקויים.
פרויקטי שדרוג כמעט תמיד מתחילים ב-Scan-to-BIM (לעיתים נדירות קיים מודל קיים מדויק), וההצלחה נמדדת מול עלות מחזור חיים מלא ויעדי פחמן ולא מול תדריך תכנון חדש - בעיית מידול שונה מהותית מעבודת בנייה חדשה, שעובדת סביב ומוגבלת על ידי מה שכבר קיים.
ניהול שרשרת אספקה רגיל מזיז חומרים ממפעל לאתר; לוגיסטיקה הפוכה היא אותו תחום שרץ בכיוון השני, והוא בדרך כלל הכיוון הקשה יותר להפוך לכדאי כלכלית.
זהו החצי החזותי של מערכת דו-חלקית - הענן מראה איפה שינוי קרה בגיליון, בעוד שטבלת השינויים מתעדת מה השינוי היה, מתי ולמה.
היא בדרך כלל מוצבת ממש ליד מסגרת הכותרת, ונותנת לכל מי שקורא שרטוט מודפס היסטוריה מיידית של כל שינוי בלי צורך להשוות אותו מול גרסה ישנה יותר.
רוויט פותחה במקור על ידי Charles River Software ונרכשה על ידי אוטודסק ב-2002 - השם שלה הוא קיצור של "Revise Instantly" (לתקן באופן מיידי), רמז לרעיון המרכזי שלה: כל קיר, דלת ולוח כמויות הם תצוגה חיה של אותו מודל משותף, כך ששינוי אחד מתעדכן בכל מקום אחר באופן אוטומטי. זו הגישה הפרמטרית מבוססת-מסד-הנתונים שכל שאר המילון הזה חוזר אליה שוב ושוב - משפחות, worksets, לוחות כמויות וה-Revit API כולם קיימים בתוך רוויט ספציפית, לא כמושגי BIM כלליים. שלוש דיסציפלינות נפרדות (אדריכלות, קונסטרוקציה, מערכות) עובדות בתוך אותו מוצר ליבה, בדרך כלל מתואמות דרך מודלים מקושרים ועבודה משותפת (worksharing) ולא דרך תוכנות נפרדות.
ממשק תכנות היישומים של רוויט
כמעט כל דבר שרוויט יכול לעשות ידנית, ה-API יכול בדרך כלל לעשות פרוגרמטית - עריכה מרוכזת של פרמטרים, יצירת דוחות מותאמים אישית, אוטומציה של משימות מידול חוזרות, או בניית כלים מותאמים אישית שלמים. Dynamo ורוב תוספי הצד השלישי לרוויט בעצמם בנויים מעל ה-Revit API; משתמשים מתקדמים כותבים ישירות מולו ב-C# או Python (דרך pyRevit) כאשר הם צריכים משהו מעבר למה שתסריטים חזותיים מציעים.
Revit LT מכסה את זרימת העבודה הבסיסית של מידול ותיעוד במחיר שהוא שבריר ממחיר הרוויט המלא, מה שהופך אותו לאטרקטיבי לעצמאים ולמשרדים קטנים - אך היעדר שיתוף העבודה ותמיכת ה-API אומרים שהוא לא יכול להשתתף במודל מרכזי רב-משתמשים או להריץ סקריפטים של Dynamo, כך שמשרדים גדלים בדרך כלל גדלים ממנו.
הפתרון של Autodesk להרחבת עבודה משותפת על פני כמה משרדים פיזיים בלי שכולם יתחברו לאותה רשת מקומית. במקום מודל מרכזי יחיד שיושב על שרת של משרד אחד, Revit Server מארח את המודל המרכזי ומאפשר לכל מופע שרת מקומי של משרד לשמור עותק מסונכרן, כך שצוות בעיר אחת וצוות בעיר אחרת יכולים לעבוד על אותו פרויקט דרך חיבור מקומי ומהיר משלהם.
הוא נדחק יותר ויותר על ידי עבודה משותפת בענן (Autodesk Construction Cloud), שעושה את אותה עבודה בלי חומרת שרת ייעודית בכל משרד, אך Revit Server עדיין נפוץ בחברות גדולות עם השקעה קיימת בתשתית IT.
פלטפורמת תיאום שמשלבת צפייה במודל מאוחד, זיהוי התנגשויות ומעקב בעיות לסביבה אחת בזמן אמת, שמטרתה להפוך פגישות תיאום לאינטראקטיביות באמת - כמה אנשים יכולים לנווט יחד באותה תצוגת תלת-ממד חיה במהלך שיחה, במקום שאדם אחד ישתף מסך בעוד כולם צופים.
היא מתחרה ישירות ב-Navisworks וב-Solibri באותו מרחב תיאום, וכמו BIMcollab, נשענת על BCF כדי לשמור על ניידות הבעיות בין תוכנות של צוותים שונים.
בקשה למידע
בקשות למידע (RFI) הן המנגנון הסטנדרטי לפתרון אי-בהירות במהלך הביצוע - כאשר משהו באתר לא תואם את המסמכים, או שהמידע של שני תחומים מתנגש, בקשת מידע מתעדת את השאלה, מנתבת אותה למי שיכול לענות, ויוצרת תיעוד כתוב של הפתרון. ריבוי בקשות מידע בפרויקט הוא לרוב סימן לבעיות תיאום שגילוי התנגשויות טוב יותר ב-BIM היה יכול לתפוס מוקדם יותר.
Rhinoceros 3D
פאנל חזית דו-עקום או צורת חופה אורגנית מתוכננים ומרוקנים ב-Rhino באמצעות הכלים הפרמטריים של Grasshopper, ולאחר מכן מובאים לרוויט כצורה מיובאת או משפחת רכיב אדפטיבי לתיעוד ותיאום עם שאר מודל הבניין.
מסגרת עבודה נפוצה מבריטניה (מהמכון המלכותי לאדריכלים בריטים) שמחלקת פרויקט לשלבים ממוספרים - מ-0 (הגדרה אסטרטגית) ועד 7 (שימוש) - כל אחד עם תוצרים ונקודות החלטה מוגדרות. זה לא תקן BIM בפני עצמו, אך מפרטי BIM מפנים אליו כל הזמן: EIR בדרך כלל יגיד איזה LOD מצופה "עד סוף שלב 3" או "עד שלב 4", ומעגן את פירוט המודל בשלב שכולם בתעשייה מכירים.
מדינות אחרות משתמשות במסגרות שלבים מקבילות משלהן, אך RIBA Plan of Work היא זו שמוזכרת מספיק לעיתים קרובות בינלאומית כדי שכדאי להכיר אותה גם מחוץ לבריטניה.
Royal Institution of Chartered Surveyors
NRM, כללי המדידה החדשים ששמאי כמויות עובדים לפיהם יום-יום, הוא עצמו פרסום של RICS - החברות בו והסטנדרטים המקצועיים שלו עומדים מאחורי חלק ניכר מהאופן שבו שמאות כמויות והערכת שווי מתבצעות בבריטניה ובעולם.
בהקשר BIM זה בדרך כלל מקבל צורה של מרשם סיכונים חי, המצוין-הפניה מול אלמנטים במודל ומטריצת אחריות, כך שהתנגשות תיאום רצינית באמת מוסלמת קדימה לפני אחת קוסמטית, במקום ששתיהן ינחתו באותה רשימת סוגיות לא מובחנת.
מרשם סיכונים בשלב תכנון עשוי לסמן אי-ודאות גיאוטכנית שלא נפתרה; מרשם בשלב ביצוע עוקב אחר עיכוב מזג אוויר חי. הוא נבדק בכל שער שלב, וסגירת רשומה בדרך כלל אומרת שהסיכון תוכנן החוצה או שהפחתה עבדה באמת - לא שהוא נשכח בשקט.
מחיר מקסימלי מובטח הוא צורה של העברת סיכון לקבלן; ביטוח אחריות מקצועית הוא צורה של העברת סיכון למבטח - אותו רעיון בסיסי שמוחל על גורמים שונים.
Autodesk Robot Structural Analysis Professional
מהנדס הקונסטרוקציה מייצא את המודל האנליטי (ראו מודל אנליטי קונסטרוקטיבי) מרוויט אל Robot, מריץ שם מקרי עומס ובדיקות תקן, ולאחר מכן מחזיר תוצאות זיון או מידות חתך - כך שהמודל הפיזי ברוויט וניתוח ההנדסה נשארים מסונכרנים במקום להתנהל כשני קבצים מנותקים.
חדר שמחשב שטח שגוי או מסרב להתמלא בסכימת צבע כמעט תמיד קשור לאי-התאמת תוחם-חדר בקרבתו - משפחת ריהוט שמוגדרת בטעות כתוחמת-חדר, או קיר מחיצה שמוגדר בטעות כלא-תוחם-חדר - מה שהופך אותה לאחת התכונות הראשונות לבדוק כאשר חישובי חדר מול מרחב נראים שגויים.
נפוץ בפרויקטים של בריאות, חינוך ואירוח עם מאות חדרים דומים אך שונים, גיליון נתוני חדר נוצר בדרך כלל ישירות מפרמטרי חדר וטבלאות ברוויט ולא נכתב ידנית - כך שהוא נשאר מסונכרן אוטומטית בכל פעם שגימור או שטח החדר משתנים במודל.
נקודת בלבול נפוצה עבור כל מי שמתאם אדריכלות עם מערכות ב-Revit: Rooms (חדרים) ו-Spaces (מרחבים) הם שני סוגי אלמנטים נפרדים שיכולים לתפוס בדיוק את אותו נפח פיזי אך שייכים לדיסציפלינות שונות ולקטגוריות Revit שונות לגמרי. אדריכלים מניחים ומתזמנים Rooms; מהנדסי מערכות מניחים Spaces (המשמשים לחישובי עומס מיזוג אוויר וניתוח אנרגיה) - ושני הסוגים לא נשארים מסונכרנים אוטומטית זה עם זה.
הפרקטיקה הטובה בדרך כלל היא לתת ל-Spaces לגזור את הגבולות שלהם ישירות מה-Rooms של המודל האדריכלי איפה שאפשר, ולבדוק מחדש את הקישור הזה בכל פעם שהפריסה האדריכלית משתנה - אחרת צוות מערכות יכול להגיע למצב שהוא מבצע חישובי עומס מול גבולות חדר שכבר לא תואמים את התכנון בפועל.
קיר סדוק אפשר לטייח אחר צהריים אחד; ניתוח שורש הבעיה הוא מה שאומר לך אם הוא פשוט יסדק שוב בגלל בעיית שקיעה שאף אחד לא באמת בדק.
Revit Project File (.rvt)
סיומת הקובץ הילידית של פרויקט Revit - rvt. - שנושאת את המודל המלא: גיאומטריה, פרמטרים, תצוגות, דפים וכל משפחה טעונה, הכל בקובץ בינארי קנייני אחד. בניגוד לפורמטים להחלפה כמו IFC או DWG, קובץ RVT לא מיועד להחלפה חוצת-תוכנות - זה Revit מדבר עם Revit, שומר על 100% מהאינטליגנציה הילידית של המודל, וזו בדיוק הסיבה שהוא פורמט הקובץ המשמש למודל המרכזי בעבודה משותפת.
קובצי RVT יכולים לגדול ובלי תחזוקה סדירה (ניקוי אלמנטים לא בשימוש, ביקורת) להצטבר בהדרגה ולהאט את כל הצוות - וזו הסיבה שהרגלי בריאות קובץ חשובים לא פחות מכישורי מידול בפרויקט ארוך טווח.
בעוד Scan-to-BIM יוצר מודל מתוך סריקה (בדרך כלל לבניינים קיימים בלי מודל), השוואת סריקה מול BIM משווה סריקה חדשה של עבודה שזה עתה נבנתה מול מודל תכנון שכבר קיים - ומסמנת סטיות לפני שהן הופכות לבעיות יקרות, שלב בקרת איכות שרץ יותר ויותר באבני דרך ביצוע מרכזיות ולא רק במסירה הסופית.
מודדים תופסים אתר או בניין קיים בסורק לייזר או בפוטוגרמטריה כדי להפיק ענן נקודות, ולאחר מכן מודליסטים משתמשים בענן הנקודות הזה כהתייחסות מדויקת כדי לבנות קירות, רצפות ואלמנטים אחרים ברוויט (או בכלי BIM אחר) במידות אמיתיות. זו הדרך הסטנדרטית לקבל מודלים אמינים של as-built לפרויקטים של שיפוץ, שדרוג וניהול נכסים שבהם אין מודל קיים מדויק.
Revit Schedule
תצוגת טבלה ב-Revit שמפרטת אלמנטי מודל ואת הפרמטרים שלהם כשורות ועמודות - לוח דלתות, לוח גימור חדרים, לוח חלונות - בנויה ישירות מנתוני מודל חיים ולא מוקלדת ידנית. מכיוון ש-Schedule היא בעצם עוד תצוגה של המודל, עריכת ערך בלוח משנה את האלמנט בפועל, ועריכת האלמנט מעדכנת את הלוח מיידית; השניים אף פעם לא יוצאים מסנכרון כמו שמודל וגיליון אקסל שמתוחזק בנפרד תמיד בסופו של דבר יוצאים.
לוחות הם גם התוצר המעשי הנפוץ ביותר של QTO: לוח חישוב כמויות חומרים עם עמודת כמות מחושבת הוא לרוב הדרך המהירה ביותר להוציא מספרים מהמודל ולתוכנית העלויות.
במקום להקליד "גימור קיר: צבע, גימור רצפה: אריחים, גימור תקרה: פאנל אקוסטי" בכל חדר בנפרד, מודליסט משייך מפתח אחד (למשל "סוג גימור 2") וטבלת מפתח הטבלה ממלאת את שלושת הערכים אוטומטית - נבנה במיוחד כדי להפוך טבלה בסגנון גיליון נתוני חדר למהירה למילוי ועקבית על פני מאות חדרים.
בפרויקט קמפוס גדול או רב-מגדלים, רשתות ומפלסים היו נמתחים אחרת על פני כל תצוגה בלי קשר לאיזה בניין הם שייכים; תיבת היקף מאפשרת למודליסט לחתוך את הנראות של הרשתות/מפלסים רק לבניין או לאזור הרלוונטי בכל תצוגה, בלי לגעת בהיקף של הרשתות והמפלסים עצמם.
זהו כלי חי וספציפי-לתצוגה לחקירה אינטראקטיבית של מודל - בניגוד לתחום גזירה, שמגביל מה תצוגה דו-ממדית מציגה, או scope box, שמגביל אילו אלמנטי datum מופיעים על פני מספר תצוגות בבת אחת.
לא כל מידע על בניין יכול להיות משותף בחופשיות - שדות תעופה, מתקני ממשל ותשתיות קריטיות זקוקים לבקרות על מי יכול לגשת למה, באיזו רזולוציה, ודרך אילו מערכות. BIM מודע אבטחה בונה תהליך מיון אבטחה לתוך תהליך העבודה הסטנדרטי של ISO 19650, ומעריך רגישות לפני שהמידע מתפרסם ולא אחרי.
מודליסט בוחר ידנית שילוב חד-פעמי ומוזר של אלמנטים - למשל, כל חלון בחזית לא סדירה אחת - שומר אותו כקבוצת בחירה בעלת שם, ויכול לבחור מחדש את אותו שילוב בדיוק שבועות מאוחר יותר בלחיצה אחת, מה שלא מסנן לפי כלל ולא קבוצה משותפת-גיאומטריה בנויים לעשות.
Shared Coordinates
הסיבה מספר אחת שמודלים "לא יושבים" אחד על השני בתיאום. לכל מודל Revit יש Project Base Point (נקודת ייחוס פנימית) ו-Survey Point (עיגון למערכת הקואורדינטות של המודד). קואורדינטות משותפות הן ההסכמה של כל הדיסציפלינות על אותו עיגון עולמי - כך שכשמקשרים את מודל הקונסטרוקציה למודל האדריכלות, הם נפגשים במקום הנכון, בגובה הנכון ובסיבוב הנכון.
לקבוע אותן נכון ביום הראשון של הפרויקט - חוסך שבועות של כאב.
משרד בדרך כלל מתחזק קובץ פרמטרים משותפים מרכזי אחד שכל פרויקט ותבנית משפחה מצביעים אליו - לפצל אותו למספר קבצים לא עקביים, ואותו פרמטר עלול להסתיים עם שני מזהים פנימיים שונים בפרויקטים שונים.
Shared Parameters
הדרך של Revit לתת לנתון אחד להתקיים בעקביות בין משפחות, פרויקטים ולוחות כמויות. פרמטר משותף מוגדר בקובץ חיצוני אחד (txt.) עם מזהה ייחודי (GUID), וכל משפחה או פרויקט שמשתמשים בו מדברים על אותו שדה בדיוק - ולכן הוא יכול להופיע ב-Schedules, בתיוגים ובייצוא IFC.
בלי פרמטרים משותפים, "דירוג אש" במשפחה אחת ו"דירוג-אש" באחרת הם שני שדות זרים שלא ייפגשו לעולם בטבלה אחת.
זהו נתיב פחות נפוץ לאותו יעד שקואורדינטות משותפות מגיעות אליו - שימושי כשכמה מודלים צריכים להסכים על מיקום עולם-אמיתי אך פרסום קואורדינטות ישירות ביניהם לא מעשי.
היא פותרת בעיית גישה ספציפית - לקוח או בודק שאין לו רישיון Revit ושלא אמור לראות את כל המודל העובד עדיין יכול לפתוח תצוגה משותפת אחת בדפדפן כדי להשאיר הערות.
מכיוון שזו טבלה חיה, הוספה או הסרה של גיליון מעדכנת את אינדקס השרטוטים אוטומטית - אין יותר צורך להקליד מחדש ידנית תוכן עניינים בכל פעם שמספר הגיליונות משתנה.
שרטוטים מפורטים ומוכנים-לייצור המופקים על ידי קבלן משנה, יצרן או מפעל - שמראים בדיוק איך רכיב ייבנה או יותקן, ברמת דיוק ששרטוטי צוות התכנון עצמו לא מנסים להגיע אליה. בתהליך BIM, שרטוטי ייצור מופקים יותר ויותר ישירות מהמודל במקום להישרטט מחדש מאפס, ברגע שהמודל מגיע ל-LOD 400.
שרטוטי ייצור בדרך כלל דורשים אישור פורמלי מצוות התכנון לפני שהייצור מתחיל, וזו בדיוק סוג אבן הדרך שנעקבת דרך מעקב הבעיות ותהליך הסקירה של פרויקט - שרטוט ייצור לא מאושר שמיוצר בכל זאת הוא טעות נפוצה ויקרה בפרויקט מתואם בצורה גרועה.
זה נשמע כמו עניין טכני, אבל זה מה שהופך CDE לעבוד בפועל: אם ניתן לשלוח שרטוט גם ישירות במייל לקבלן משנה, כעת יש שתי גרסאות במחזור ואין דרך לדעת איזו מהן עדכנית. נקודת כניסה יחידה היא מה ששומרת על ה-CDE כמקור האמת היחיד האמיתי במקום עוד עותק אחד של הקבצים.
זהו ההיגיון שמאחורי המשיכה ל-design-and-build - במקום שלקוח ינהל צוות תכנון וקבלן בנפרד, ויתווכח על אשמת מי בעיה, יש רק דלת אחת לדפוק עליה.
העיקרון היסודי שמאחורי רוב המשמעת התהליכית של BIM: מידע על פרויקט צריך להתקיים במקום מוסמך אחד בדיוק, כשכל השאר - שרטוטים, לוחות, דוחות - נוצר ממנו, ולא מתוחזק כעותקים נפרדים ומקבילים שבהכרח יוצאים מסנכרון. לוח שנשלף חי מהמודל הוא מקור אמת יחיד בפעולה; גיליון אקסל שמישהו מתחזק ידנית לצד המודל הוא ההפך.
ה-CDE הוא המנגנון הארגוני שהופך מקור אמת יחיד לאפשרי ברמת הפרויקט - מקום מוגדר ומוסכם שבו הגרסה הנוכחית והנכונה של כל פיסת מידע חיה, כך שאף אחד לעולם לא עובד מעותק מיושן בלי לדעת.
זהו הביצוע הפיזי של תוכנית לוגיסטיקת האתר - התוכנית על נייר הופכת לגדרות, תאים ושער מתחם בעולם האמיתי.
באתר עירוני צפוף זהו לעיתים קרובות המסמך השנוי ביותר במחלוקת בעבודה - וגם בדיוק סוג התוכנית שחזרה דיגיטלית משמשת לבדוק לפני שמתחייבים אליה על נייר.
מודל לוגיסטיקת אתר יושב לצד מודל הבניין הקבוע ומשתנה ככל שהביצוע מתקדם - טווח הגעה של מנוף ואזור אחסון חומרים שהגיוניים בחודש השני עשויים להזדקק לזוז לגמרי עד החודש השמיני, ותכנון הרצף הזה במודל תופס התנגשויות שתוכנית אתר דו-ממדית סטטית הייתה מפספסת.
סקר פיזי מדויק של אתר - גבולות, מפלסים קיימים, תשתיות, מבנים קיימים - שמבוצע על ידי מודד מוסמך ומשמש כבסיס אמת מדויק בשטח שהמודל נבנה עליו. סקר שטח בדרך כלל מיובא כשרטוט מקושר או קובץ נקודות ונקשר לקואורדינטות המשותפות של הפרויקט, ומעגן כל מה שממודל לאחר מכן לעולם האמיתי.
דילוג או מיהור סקר שטח נכון הם אחד המקורות הנפוצים ביותר לבעיות יקרות בהמשך: מבנה שממודל מול נתוני שטח לא מדויקים יכול להגיע למפלס רצפה גמור שגוי, גבולות מגרש לא מיושרים, או תכנון שלא באמת מתאים לטופוגרפיה האמיתית ברגע שהבנייה מתחילה.
היא עוקבת אחר פסולת לפי סוג ויעד - מה ממוחזר, מה משמש שוב באתר, ומה בפועל מגיע למזבלה - ויותר ויותר קשורה ליעדי הכלכלה המעגלית והפחמן הגלום של הפרויקט, במקום להיות מטופלת כמסמך ציות עצמאי.
הרבה סטודנטים לאדריכלות ומשרדים קטנים מתחילים קונספט ב-SketchUp כי עקומת הלמידה שלו הרבה יותר מתונה מהגישה הפרמטרית של רוויט - המחיר הוא שמודל SketchUp לא נושא נתוני בניין אמיתיים (בלי סוגי קירות, בלי טבלאות), כך שהוא בדרך כלל נבנה מחדש כמשפחות רוויט ראויות ברגע שהתכנון מתקבע, ולא מיובא כמכלול.
זהו הפורמט שמאחורי ספריית ה-3D Warehouse החינמית שממנה משתמשי SketchUp רבים שואבים דגמי ריהוט והקשר אתר - שימושי לעבודת נפחים ותפיסה מוקדמת, אם כי הוא לא נושא דבר מהמבנה הפרמטרי והעשיר בנתונים שיש למשפחת Revit.
"רשימת ליקויים" (snag list, הנקראת גם punch list) נסקרת ומצולמת באתר, ויותר ויותר נרשמת ישירות מול אלמנטים במודל ה-BIM באמצעות אפליקציות ניידות או קבצי סוגיות BCF, כך שכל ליקוי מקושר לאובייקט, למיקום ולגורם האחראי המדויקים, במקום לשורה חופשית בגיליון אלקטרוני.
סגירת כל פריט ברשימת התיקונים היא מה שתעודת תיקון ליקויים מאשרת באופן פורמלי שקרה.
BSRIA Soft Landings
מסגרת עבודה (במקור מ-BSRIA בבריטניה) לסגירת הפער בין האופן שבו מבנה תוכנן לפעול לבין האופן שבו הוא באמת מתפקד לאחר שאנשים עוברים אליו. Soft Landings שומר על מעורבות צוות התכנון והבנייה לתקופה לאחר המסירה - בדרך כלל שנה או יותר - כדי לכוונן מערכות, לענות על שאלות המפעיל ולהשוות נתוני ביצועים אמיתיים מול כוונת התכנון המקורית.
הוא משתלב באופן טבעי עם BIM: נתוני ה-AIM וה-COBie שהופקו במהלך הפרויקט הופכים לקו הבסיס שצוות ה-Soft Landings מודד מולו, והלקחים שנלמדים מוזנים חזרה ל-EIR של הפרויקט הבא.
Solibri Model Checker
פלטפורמת בדיקת מודלים ותיאום (כיום בבעלות Nemetschek) שנבנתה במיוחד סביב openBIM ו-IFC, ולא סביב כלי מידול ספציפי כלשהו. החוזק של Solibri הוא בדיקה מבוססת-כללים: במקום רק לאתר התנגשויות ויזואלית, הוא יכול לאמת מודל אוטומטית מול קבוצת כללים מוגדרת - מרחקי מילוט אש, מרווחי נגישות, מידע חסר, עמידה ב-LOD - ולסמן כל הפרה בדוח מובנה.
זו חלופה או בן-לוויה נפוץ ל-Navisworks, בעיקר בפרויקטים שנשענים רבות על תהליכי openBIM ורוצים בדיקה שחורגת מעבר להתנגשויות גיאומטריות אל איכות המידע בפועל.
גילוי התנגשויות היא הבדיקה האוטומטית; תיאום מרחבי הוא התחום הרחב יותר שהיא משרתת, כולל דברים שבדיקת התנגשות לבדה לא תתפוס, כמו השארת מרווח מספיק סביב שסתום כדי שטכנאי יוכל להגיע אליו.
אם השרטוטים מראים מה הולך איפה, המפרט אומר כמה טוב זה צריך להיות - באיזה תקן חומר חייב לעמוד, איך צריך להתקין אותו, ואיך בודקים או מסמיכים אותו. בפרויקטי BIM, סעיפי מפרט (המאורגנים לרוב דרך MasterFormat או מקבילה לאומית כמו NRM) מקושרים יותר ויותר ישירות לאלמנטים במודל במקום לחיות במסמך נפרד לחלוטין.
במקום לייצא קובץ IFC או Navisworks ולייבא אותו מחדש בכל פעם שמשהו משתנה, Speckle שומרת "זרמים" חיים ומגורסים של נתוני מודל, שכלים שונים יכולים לדחוף אליהם ולמשוך מהם - קרוב יותר לאופן שבו עובד מאגר קוד מאשר החלפת קבצים מסורתית. הכלי צובר תאוצה כאלטרנטיבה קלה יותר וניתנת לאוטומציה להחלפת קבצים, בייחוד לצוותים שכבר כותבים סקריפטים ב-Dynamo או Grasshopper.
הוא שימושי ברגע ששני חצאים ממה שהיה קיר רציף אחד צריכים תכונות שונות - דירוג אש שונה מעבר לנקודה מסוימת, למשל - בלי לשרטט מחדש כלום מאפס.
תוכניות ניקוז אתר וגג תלויות בו רבות - סדרה של נקודות גובה על פני משטח משופע היא הדרך שבה בודק מאשר שמים באמת יזרמו לעבר ניקוז ולא יצטברו במקום לא מכוון.
השלבים הממוספרים של RIBA Plan of Work הם דוגמה מוכרת - כל שער שלב קיים כדי למנוע מפרויקט להחליק לתכנון מפורט לפני שהלקוח אישר בפועל את הקונספט שעליו הוא מבוסס.
הוא החליף את כלי המדרגות הישן מבוסס-הסקיצה כברירת המחדל מסיבה - כל רכיב נשאר ניתן לעריכה באופן עצמאי, מה שמטפל בגאומטריית מדרגות מציאותית ומביכה בצורה חלקה הרבה יותר.
מטריצת אחריות אומרת לך מי עושה מה; ניהול בעלי עניין הוא העבודה הרחבה והמתמשכת יותר של לשמור על כל מי שאכפת לו מהתוצאה מעודכן ומיושר, בין אם הוקצתה לו משימה פורמלית ובין אם לא.
תקן להחלפת נתוני מודל מוצר
כאשר רכיב שמודל ברוויט צריך להיות מיוצר בפועל - תושבת קיר מסך מותאמת אישית או חלק פלדה קונסטרוקטיבי - STEP הוא לעיתים קרובות הפורמט שמעביר את הגיאומטריה המדויקת שלו למכונות CNC ולתוכנות CAD לייצור, מכיוון שהוא נבנה לדיוק הנדסי-מכני ולא לתיעוד אדריכלי.
ייצוג מפושט של הקונסטרוקציה - קורות ועמודים מצומצמים לקווי מרכז, קירות מצומצמים למישורים - שתוכנת ניתוח קונסטרוקטיבי בפועל מחשבת מולו, רץ לצד המודל הפיזי המלא (הגיאומטריה האמיתית שכולם אחרים רואים ומתאמים מולה) בתוך אותם אלמנטי קונסטרוקציה של Revit.
שני המודלים יכולים להתרחק זה מזה אם לא מנוהלים בזהירות: הזזת גיאומטריה פיזית של עמוד לא תמיד מזיזה אוטומטית את הקו האנליטי שלו באותו אופן, וחישובי מהנדס קונסטרוקציה אמינים רק כמו מידת ההתאמה של המודל האנליטי לכוונת התכנון הפיזית האמיתית.
ניתוח אלמנטים סופיים או מעבר אופטימיזציית מבנה בדרך כלל מזינים אותו ישירות - מסמך החישובים הוא הרשומה הפורמלית והניתנת-לבדיקה של מה שהניתוח הזה בפועל הסיק.
זהו ניתוח אלמנטים סופיים שמופנה למטרה ספציפית - לא רק בדיקה האם תכנון עובד, אלא איטרציה לעבר התכנון הרזה ביותר שעדיין עובד.
מסמכי חוזה AIA מגדירים אותה במדויק כי כל כך הרבה דברים אחרים תלויים בתאריך הזה - תקופות אחריות, שחרור ריטנשן וחובות הביטוח של הלקוח לעיתים קרובות כולם מתחילים להימנות ממנו.
מחקר מסלול שמש מהיר בתוך רוויט עצמו יכול לתפוס בעיית הצללה ברורה או לאשר שאמצעי הצללה עובד בהיפוך הקיץ, בלי צורך לייצא לכלי סימולציית ביצועי בניין ייעודי בכל שאלת תכנון מוקדמת.
ספק ייצור דיגיטלי אמין רק כמו שרשרת האספקה שמזינה אותו בחומרים בזמן - ולכן משלוח מעוכב שלוש רמות למטה עדיין יכול לפגוע בנתיב הקריטי חודשים אחר כך.
זהו הצד המקביל של הרכש ליעדי פחמן גלום - תכנון דל-פחמן עדיין יכול להיכשל ביעדי הקיימות שלו אם החומרים שמאחוריו נרכשים ממי שהכי זול בלי קשר לטביעת הרגל שלהם.
Synchro Pro
במקום שלוח זמנים ומודל יתקיימו כשני מסמכים מנותקים, Synchro מקשרת כל משימה בלוח הזמנים לאלמנטים הספציפיים שהיא בונה, כך שכל הצוות יכול לצפות ויזואלית ב"גדילת" הבניין לאורך זמן ולזהות מיידית קונפליקטים ברצף שלוח זמנים מבוסס-גיליון בלבד לעולם לא היה חושף.
בעוד שדפדפן הפרויקט מארגן מודל לפי תצוגה, דפדפן המערכות מארגן אותו לפי מערכת - הכלי שמהנדס MEP פונה אליו כדי לבחור כל אלמנט בריצת תעלה ספציפית אחת בבת אחת, בכל מקום שהיא מופיעה.
זהו הפיצול הבסיסי שכל משתמש Revit חדש צריך ללמוד: משפחות טעינה (כמו דלת או רהיט) חיות בקבצי RFA ונטענות לפרויקט, בעוד שמשפחות מערכת תמיד מתארחות בפרויקט, ומועתקות בין פרויקטים דרך transfer project standards במקום טעינת משפחה.
העתקת אלמנט בין שני פרויקטים פתוחים, או השוואה מהירה של פרט בין עבודה נוכחית לפרויקט התייחסות מהעבר, הופכת להחלפת כרטיסייה פשוטה במקום החלפה בין שני חלונות רוויט נפרדים לחלוטין - נוחות זרימת עבודה שרוב המשתמשים החדשים מעריכים רק אחרי שהרגישו את החיכוך של הדרך הישנה.
תג הוא לא טקסט עצמאי - הוא תצוגה חיה המחוברת לפרמטר של אלמנט מודל ספציפי, כך שאם הערך של אותו אלמנט משתנה (או שהאלמנט נמחק), התג מתעדכן או נעלם יחד איתו, מה שמונע מתיעוד השרטוטים לסטות בשקט מהמודל.
היא מכניסה את הבעלים, המתכנן והקבלן לאותו חדר כבר מההתחלה, ומתייחסת לעלות היעד כאילוץ תכנון ולא כאומדן שמופק לאחר שהתכנון כבר נקבע - קרובה ברוחה יותר ל-integrated project delivery מאשר לרצף מסורתי של design-bid-build.
בתוך צוות משימה ב-BIM (כפי שמוגדר ב-ISO 19650 וב-BS 1192), מנהל מידע המשימה מתכנן ומכוון את ההפקה השוטפת של המידע, מוודא שהצוות פועל לפי מוסכמות השמות והסטנדרטים של הפרויקט, ובודק מידע לפני שהוא משותף לתיאום. בשונה מתפקיד מנהל המידע הרחב, שפועל ברמת הפרויקט כולו ולא בתוך צוות משימה בודד.
צוות חד-דיסציפלינרי - מהנדסי הקונסטרוקציה, יועצי המערכות, מומחי החזית - שממונה להפיק חלק ספציפי ממידע הפרויקט, תוך עבודה תחת תיאום ה-Lead Appointed Party. כל Task Team אחראי על ה-TIDP שלו, ועל מסירת מודל הדיסציפלינה שלו ל-LOD המוסכם בכל אבן דרך.
בשפה יומיומית זה פשוט "אחד מצוותי היועצים בפרויקט" - התרומה של ISO 19650 היא לתת ליחס הזה שם מדויק ומקום מוגדר במבנה מסירת המידע הכולל, במקום להשאיר אותו משתמע.
בעוד ש-Revit הוא כללי לאורך כל תחום, Tekla צוללת לעומק באחד - פרטי חיבור פלדה מדויקים מספיק כדי להניע ייצור דיגיטלי ישירות, ולכן נפוץ לראות מודל מבני של Tekla מאוחד עם מודל אדריכלי של Revit.
Template (.rte)
קובץ ההתחלה של כל פרויקט - וה-DNA של סטנדרט המשרד. טמפלייט (rte. ברוויט) מגיע טעון מראש עם הגדרות תצוגה, View Templates, משפחות, סגנונות קו, דפי הדפסה, פרמטרים ושמות שכבות - כך שכל פרויקט חדש מתחיל מאורגן ואחיד.
משרד עם טמפלייט טוב מייצר תוצרת עקבית ומהירה; משרד בלי טמפלייט ממציא את הגלגל בכל פרויקט. הקמת טמפלייט משרדי היא אחת ההשקעות המשתלמות ביותר בהטמעת BIM.
הן עזר להצבה, לא תיעוד - סמל מידה קבועה קטן מופיע לצדן בדיוק כדי שמשתמש יוכל לקדם קריאה זמנית שימושית למידה אמיתית בשרשרת מידות לפני שהיא נעלמת.
זהו תחום הנדסי נבדל מהתכנון המבני הקבוע, ומקור תכוף לתאונות באתר כשמתייחסים אליו כמחשבה בדיעבד במקום לתכנן ולבדוק אותו כראוי.
תחת Design-Bid-Build, איכות חבילת המכרז קובעת ישירות עד כמה ההצעות שחוזרות ניתנות להשוואה ואמינות בפועל - מודל או מפרט לא שלמים או עמומים בשלב המכרז הם אחד המקורות הנפוצים ביותר להוראות שינוי יקרות ברגע שהביצוע מתחיל.
זוהי חלופה קלת-משקל יותר לערבות צמודה, שמשיגה תוצאה מעשית דומה עם פחות ניירת נפרדת עבור כל גורם חדש שזקוק להגנה.
היא עצמה משפחת סימון, בנויה או ערוכה בהתאמה אישית לכל משרד, וזה מה שכל טבלת שינויים ורשימת גיליונות מוצגת לצדו בסופו של דבר.
Toposurface היה גיאומטרי בלבד - צורה בלי שכבות חומר או נתוני כמות - בעוד Toposolid מתנהג כמו אלמנט בניין ראוי: הוא יכול לארח תת-אלמנטים, להתפצל לשכבות (אדמת גן מעל תת-קרקע), ולהזין טבלאות באותו אופן שהרכבת רצפה או קיר עושה, וסוגר פער ותיק בין מידול אתר למידול בניין.
באתר עירוני צפוף היא פועלת יד ביד עם תוכנית לוגיסטיקת האתר, אך מתמקדת ספציפית ברשת הכבישים הציבורית ולא בגבול האתר עצמו.
מכיוון שמשפחות מערכת ותבניות תצוגה לא ניתנות לטעינה כמו משפחת RFA, זהו המנגנון בפועל שמשרדים משתמשים בו כדי לשמור על עקביות סטנדרטים בין פרויקטים - בדרך כלל מופעל פעם אחת מול קובץ תבנית האב של המשרד ולא מפרויקט לפרויקט.
מסמך שידור (Transmittal) הוא השובל הנייר של חילופי מידע - הוא מציין את השולח, הנמען, המטרה (לידיעה, לבדיקה, לביצוע), מספרי גרסה ורשימה של כל קובץ שנכלל, כך שלשני הצדדים יש תיעוד משותף וניתן לביקורת של מה שהונפק ומתי. בפרויקטי BIM הוא בדרך כלל נוצר אוטומטית על ידי סביבת הנתונים המשותפת כאשר סט מסמכים משנה מצב.
זהו אחד הכלים הראשונים שמשתמש Revit חדש לומד - לחיצה על שני קירות שלא ממש נפגשים וגרימה להם להתחבר בצורה נקייה במקום גרירה ידנית של נקודות קצה.
פלטפורמת שיתוף הפעולה בענן של Trimble - סביבה בסגנון CDE לשיתוף, צפייה ותיאום מודלים בין צוותים, נפוצה במיוחד בפרויקטים שמשתמשים ב-Tekla Structures או כלי Trimble אחרים, ונפוצה בהרחבה בעבודות תשתית ואזרחית כבדה לצד פרויקטי מבנים.
היא ממלאת תפקיד פונקציונלי דומה ל-Autodesk Construction Cloud, אך מאקוסיסטם ספק שונה - באיזה פרויקט תפגשו אותה בדרך כלל תלוי באיזו תוכנת מידול הדיסציפלינה הקונסטרוקטיבית או התשתיתית משתמשת.
כלי ויזואליזציה אדריכלית בזמן אמת מבית Epic Games (יוצרי מנוע Unreal ו-Fortnite), שמציע את אותו ערך של "מעבר פוטו-ריאליסטי מיידי" כמו Enscape, אך בנוי על טכנולוגיית מנוע משחקים אמיתית. מודלים נכנסים מ-Revit וכלי BIM אחרים דרך Datasmith, צנרת הייבוא הייעודית של Epic, ששומרת על חומרים והיררכיה טוב בהרבה מייצוא גנרי.
Twinmotion ו-Enscape תופסים בערך את אותו נישה ומושווים לעיתים קרובות ישירות - הבחירה ביניהם בדרך כלל תלויה בהעדפת סגנון רינדור, צרכי תמיכת VR, ואיזה מהם רישיונות קיימים של המשרד כבר מכסים.
היא מכניסה את קלט הבנייה של הקבלן לתכנון מוקדם יותר ממכרז חד-שלבי מסורתי - קרובה ברוחה יותר ל-early contractor involvement מאשר לפיצול design-bid-build טהור.
אחד הרעיונות הראשונים שבאמת מבלבלים כל מי שחדש ל-Revit. פרמטר טיפוס (Type) משותף לכל מופע מונח של אותו טיפוס - שנו את דירוג האש בדלת אחת מסוג "דלת יחיד 900 מ״מ" וכל דלת מאותו טיפוס בדיוק מתעדכנת, כי זו למעשה הגדרה משותפת אחת. פרמטר מופע (Instance) שייך לאלמנט מונח ספציפי אחד בלבד - מספר הסימון שלו, הקומה שלו, הגובה המדויק שלו מעל הרצפה - ושינוי שלו לא משפיע על שום דבר אחר.
הבנה נכונה של ההבחנה הזו היא ההבדל בין מודל שבו תיקון אחד מתקן ארבעים דלתות בבת אחת, לבין מודל שבו מתקנים ארבעים דלתות אחת-אחת ידנית.
במקום לטעון משפחה שלמה עם כל גודל אפשרי (למשל, משפחת דלתות עם ארבעים שילובי רוחב/גובה) ולבחור אחד, קטלוג סוגים (Type Catalog) מאפשר למשתמש לבחור בדיוק את הסוג שהוא צריך ישירות מתיבת הדו-שיח של ההוספה - ושומר על פרויקטים קלים יותר וניהול משפחות נקי יותר, במיוחד עבור תוכן יצרנים עם וריאנטים רבים.
כך שרטט בודק שקיר בקומה השנייה אכן מתיישר עם הקיר שתומך בו למטה, בלי לעבור הלוך ושוב בין שתי תצוגות תוכנית נפרדות.
מיון מאוחד לתעשיית הבנייה
Uniclass מקבצת מידע תחת טבלאות כמו מערכות, מוצרים, מרחבים/מיקומים וישויות, וכל פריט מקבל קוד אלפאנומרי קצר (למשל Ss_25_10 עבור מערכת קיר) שנשאר עקבי בין אם הוא מוזכר בשרטוט, בטבלת כמויות או בקובץ מסירה של COBie. השיטה נפוצה בעיקר בפרויקטים בבריטניה ובחבר העמים, ומתחברת באופן טבעי לשדות המיון הקיימים כבר בפרמטרים של משפחות וחומרים ברוויט.
מיון Uniformat לאלמנטים בבניין
בעוד MasterFormat מארגנת מידע לפי מקצוע (בטון, בנייה, דלתות וחלונות), Uniformat מקבצת את אותו בניין לפי ממה הוא בפועל בנוי - תת-מבנה, מעטפת, פנים, מערכות - מה שהופך אותה לשימושית במיוחד לאומדני עלות מוקדמים וכימות כמויות אלמנטרי, עוד לפני שקיימים מפרטים ספציפיים למקצוע.
Twinmotion מוותרת על חלק מהגמישות הגולמית של Unreal תמורת זרימת עבודה מהירה בהרבה ומותאמת ל-AEC - סטודיו שזקוק לשליטה יצירתית מלאה בתאורה, חומרים ואינטראקטיביות מעבר למה שהממשק המפושט של Twinmotion מציע, יפנה לעיתים קרובות ישירות ל-Unreal עצמה.
תיאור סצנה אוניברסלי
היכולת של USD לשכב ולמזג סצנות ענקיות ממקורות מרובים באופן לא הרסני היא מה שהופך אותו לאטרקטיבי עבור AEC מעבר לקולנוע - ניתן להמיר מודל רוויט ל-USD ולשלב אותו עם מקורות נתונים אחרים בסביבת זמן אמת משותפת, בלי לשטח הכול לקובץ קבוע אחד כפי שפורמטים ישנים יותר עושים.
בשונה ממנועי זמן אמת שנבנו לסיורים מהירים בשלב התכנון (Enscape, Twinmotion, Lumion), רינדורים ב-V-Ray לוקחים יותר זמן לחישוב בתמורה לתאורה וחומרים מדויקים יותר פיזית - הכלי המועדף כשהתמונה הסופית עצמה היא התוצר, כמו לוח תחרות או תמונת שיווק מרכזית.
תהליך מובנה לסקירת תכנון ספציפית כדי למצוא דרכים לצמצם עלות תוך עדיין לעמוד בתפקוד ואיכות נדרשים של הפרויקט - החלפת חומרים, פישוט פרט, שאלת האם מערכת שצוינה בעצם נחוצה - בניגוד לפשוט "לחתוך פינות", שמקריב איכות כדי לחסוך כסף.
BIM הופך הנדסת ערך למושכלת הרבה יותר: מכיוון שמודל נושא נתוני QTO ועלות חיים, ההשפעה האמיתית על עלות וכמות של החלפה מוצעת ניתנת לבדיקה ישירות במודל, במקום להיאמד בערך על נייר, וההשפעה של שינוי מתפשטת בצורה גלויה דרך כל לוח ושרטוט שתלוי בו.
בעוד שהנדסת ערך היא בדרך כלל תרגיל ממוקד שמופעל על תכנון ספציפי לאחר שהוא כבר קיים, ניהול ערך פועל לאורך כל מחזור חיי הפרויקט, ומעצב את התכנית וההחלטות כבר מההתחלה במקום לייעל בדיעבד.
זהו כלי אבחוני ש-lean construction שואל ישירות מהתעשייה - שרטוט הזרימה בפועל של תהליך הוא לעיתים קרובות הדרך המהירה ביותר לראות היכן הוא באמת נשבר.
Virtual Design & Construction
מונח שתפגשו הרבה במודעות דרושים ובחברות בנייה גדולות. VDC הוא הגישה הניהולית שעוטפת את ה-BIM: שימוש במודלים וירטואליים כדי לתכנן את הבנייה עצמה - תיאום, לוחות זמנים, לוגיסטיקת אתר ותקציב - לפני שמגיעים לשטח.
אם BIM הוא המידע והמודל, VDC הוא האופן שבו צוות הפרויקט משתמש בהם כדי לקבל החלטות ביצוע. בפועל, תפקיד "מתאם BIM" בחברה קבלנית קרוב מאוד לעבודת VDC.
ערכות הכלים שלה לנוף ולתעשיית הבידור חזקות באופן יוצא דופן בהשוואה ל-Revit, ולכן היא הבחירה הנפוצה יותר מחוץ לעבודת תכנון מבנים טהורה.
שדות הסטטוס/גרסה של CDE עצמו הם מנגנון בקרת הגרסאות שלו ברמת הפרויקט; מערכת הקובץ המרכזי-מקומי של Revit היא אותו רעיון ברמת הקובץ הבודד.
במקום לצבוע מחדש כל קיר ידנית, מסנן מבט (View Filter) אומר "כל קיר שבו דירוג האש שווה ל-2 שעות הופך לאדום במבט הזה" - מוחל לפי מבט או תבנית מבט, גרפי בלבד וניתן לביטול מלא מכיוון שהוא אף פעם לא נוגע בנתוני המודל בפועל. שימושים נפוצים כוללים קידוד שלבים, דיסציפלינות או דירוגי אש בצבע לאורך כל סט שרטוטים בבת אחת.
תוכנית שמציגה משטח מטבח אך לא את הארונות העליונים מעליו, או שמפספסת קורה נמוכה שאמורה להופיע כקו מקווקו, היא כמעט תמיד בעיית הגדרת טווח תצוגה ולא שגיאת מידול - אחד המקורות הנפוצים ביותר לבלבול אצל כל מי שחדש בקריאה או הפקה של תוכניות רוויט.
אוסף שמור של הגדרות תצוגה - החרגות נראות וגרפיקה, קנה מידה, רמת פירוט, שלב, טווח תצוגה ועוד - שניתן להחיל על תצוגה בלחיצה אחת, ואפשר גם לנעול כדי שאף אחד לא ישנה אותו בטעות. View Templates הם האופן שבו משרד שומר על כל תוכנית קומה, חתך וחזית שנראים עקביים לאורך פרויקט (ולאורך כל פרויקט, אם התבניות חיות בטמפלייט המשרדי), במקום שכל חבר צוות יגדיר הגדרות נראות ידנית.
הם אחד הכלים בעלי המנוף הגבוה ביותר במשרד רוויט מנוהל היטב: סט טוב של View Templates הופך את "לגרום לשרטוט הזה להיראות נכון" ממשימה ידנית של 20 דקות לבחירה מרשימה נפתחת של שתי שניות.
החלפות נראות/גרפיקה (VG)
חלון ה-VG (שנפתח בקיצור VG או VV) הוא המקום שבו מודליסט מכוונן משקלי קו, דוגמאות הצללה או נראות קטגוריה בתצוגה בודדת באופן מיידי - תבנית תצוגה, לעומת זאת, אורזת מערכת שלמה של הגדרות VG והגדרות תצוגה אחרות לפריסט אחד לשימוש חוזר וניתן לנעילה, המוחל על תצוגות רבות בבת אחת.
בפרויקט גדול, קובץ רוויט בודד הופך כבד מדי לעבודה יעילה של מישהו, ולכן הצוות מסכם מראש כיצד לפצל אותו - לרוב לפי מגדל, טווח קומות או אזור - ומתעד היכן נמצאים גבולות כל פיצול, כדי שהמודלים המקושרים יישארו מיושרים ושום היקף לא ייפול בין שני נפחים בלי בעלים.
זוהי חלופה פשוטה ומובנית לייצוא מודל ל-Twinmotion או Lumion עבור מעוף מרונדר במלואו - נאמנות נמוכה יותר, אך מיידית, ללא תוכנה נוספת מעורבת.
זהו אחד המקורות הנפוצים ביותר לפינות מבלבלות בתוכנית - החיבור האוטומטי בדרך כלל מבצע זאת נכון, אך ביטול או עקיפה שלו ידנית הוא תיקון שגרתי כשהוא לא.
הוא עוקב אחר הנתיב של הקיר עצמו באופן אוטומטי, כולל סביב פינות ופתחים, במקום להיות מצויר כמקטעים ישרים נפרדים שהיו צריכים עדכון ידני בכל פעם שהקיר משתנה.
ההתראות המובנות ש-Revit מעלה כשמשהו במודל מוטל בספק גיאומטרית או לוגית - קירות חופפים, אלמנטים בקומה הלא נכונה, חדרים שלא סגורים במלואם - בלי לחסום בפועל את המשתמש מלהמשיך לעבוד. מספר קטן של אזהרות הוא נורמלי בכל פרויקט פעיל; מודל עם אלפי Warnings מצטברות ומתעלמות הוא בדרך כלל סימן לבעיות תיאום או איכות עמוקות יותר שלא טופלו.
סקירה ומיון של רשימת האזהרות מדי פעם - תיקון מה שאמיתי, הבנה והתעלמות ממה שחיובי-כוזב - הם חלק סטנדרטי מבדיקות בריאות המודל שמתאם BIM מריץ לפני אבן דרך או מסירה.
קרום גג יכול לשאת אחריות יצרן ל-20 שנה למרות שתקופת אחריות הליקויים הכללית של הפרויקט כולו מסתיימת אחרי 12 חודשים - מעקב אחרי אילו אחריות מוצר ספציפיות חלות על אילו אלמנטים במודל הוא בדיוק סוג המידע הלא-גיאומטרי שמודל מידע נכס נבנה כדי לשאת לתוך שלב התפעול.
בעוד ש-LEED ו-BREEAM מתמקדים בעיקר בטביעת הרגל הסביבתית של מבנה, WELL Building Standard מסמיך את האופן שבו המבנה משפיע על בריאות ורווחת המשתמשים בו - איכות אוויר ומים, תאורה, אקוסטיקה, נוחות תרמית ושיקולי בריאות נפשית. הוא מתבקש יותר ויותר לצד LEED או BREEAM ולא במקומם, בעיקר בפרויקטי משרדים ומגורים שבהם חוויית המשתמש היא נקודת מכירה.
כמו בהסמכות האחרות, הנתונים שהערכת WELL צריכה - רמות אור יום, קצבי אוורור, שקיפות חומרים - חופפים במידה רבה למידע שמודל BIM מפותח כראוי כבר יכול לספק.
התמונה המלאה של הפחמן של מבנה לאורך כל מחזור החיים שלו: פחמן גלום מחומרים ובנייה, פחמן תפעולי מעשרות שנות צריכת אנרגיה, ופחמן סוף-חיים מהריסה או פירוק אפשריים בעתיד, הכל מחובר יחד. הערכת Whole Life Carbon דורשת בדיוק את סוג הנתונים העשירים והמובנים ש-BIM נבנה כדי להחזיק - כמויות, סוגי חומרים, אורך חיים צפוי, ביצועי אנרגיה - שנשלפים ממודל אחד במקום להיאסף ידנית מדוחות נפרדים.
זה יותר ויותר מה שרגולציות והסמכות כמו LEED ו-BREEAM נעות לכיוון דרישתו, ומחליף הערכות ישנות יותר שהסתכלו רק על אנרגיה תפעולית בבידוד.
עלות מחזור חיים מלא (WLC)
מערכת מיזוג זולה יותר לבנייה יכולה בקלות לעלות יותר על פני 30 שנות צריכת אנרגיה וחלקי חילוף ממערכת יקרה יותר ויעילה יותר - עלות מחזור חיים מלא היא המשמעת של השוואת אפשרויות על פני ציר הזמן המלא הזה במקום המספר הראשוני, תוך שימוש באותן כמויות ונתוני מערכת שכבר נתפסו במודל.
Work in Progress
האזור הפרטי בתוך ה-CDE שבו כל דיסציפלינה עובדת על המודל שלה לפני שמשתפת אותו עם הצוות הרחב יותר. מידע WIP לא נבדק ולא אושר - הוא קובץ העבודה הגולמי.
קידום מידע מ-WIP לאזור ה-Shared הוא צעד רשמי: פירושו שהמידע נסקר ומוכן לשאר הצוות לתאם כנגדו.
Uniformat ו-Omniclass הם בעצם מבני WBS מתוקננים עבור אלמנטי מבנה - וזו בדיוק הסיבה שההיררכיה של מודל BIM בנוי היטב כה לעיתים קרובות מתיישרת גם עם פירוק העלות והלוח זמנים של הפרויקט.
משטח הייחוס השטוח הבלתי-נראה ש-Revit משתמש בו בכל פעם ששורטטים או מניחים משהו - כברירת מחדל הוא קשור לתצוגה או לקומה הנוכחית, אך ניתן להגדיר אותו במפורש לפאה, מישור ייחוס, או רשת ספציפית כדי לשרטט במקום שאינו שטוח ואופקי, כמו על גג משופע או קיר בזווית.
בלבול לגבי "למה האלמנט הזה הלך למקום שלא ציפיתי" הוא לעיתים קרובות בעצם בעיית Work Plane מוסווית - Revit הניח את הגיאומטריה החדשה יחסית למישור שהיה פעיל, לא בהכרח לזה שהמשתמש הניח. הבנה מפורשת של מישורי עבודה היא אחת הדרכים המהירות ביותר להפסיק להיאבק בלוגיקת המיקום של Revit ולהתחיל להשתמש בה בכוונה.
המנגנון בתוך עבודה משותפת שמחלק מודל מרכזי אחד לחלקים לוגיים הניתנים לעריכה עצמאית - מעטפת וליבה, פנים, אתר, מערכות - כך שכמה אנשים יכולים לעבוד על אותו קובץ בו-זמנית בלי לדרוך אחד על השני כל הזמן. כל אלמנט שייך ל-Workset אחד בדיוק, וכל משתמש יכול לבחור אילו Worksets פתוחים וגלויים בסשן שלו, וזו גם הדרך שבה מודל גדול וכבד נשאר עביד: סגירת Worksets שלא צריכים מאיצה משמעותית את הסשן המקומי.
Worksets עוסקים בחלוקת בעלות בתוך קובץ אחד; אם צריך להביא קובץ נפרד באמת, זה מה שמודלים מקושרים נועדו עבורו.
מודל מרכזי ו-Worksets
המושגים שכל ג'וניור שומע בשבוע הראשון בפרויקט אמיתי. Worksharing הוא המצב ברוויט שמאפשר לצוות שלם לעבוד על מודל אחד בו-זמנית: הפרויקט חי במודל מרכזי (על שרת או בענן), כל אחד עובד על עותק מקומי מסונכרן, והשינויים חוזרים למרכזי עם "Synchronize with Central". Worksets מחלקים את המודל לחלקים לוגיים - מעטפת, פנים, פיתוח - כך שאפשר לנהל בעלות ותצוגה לפי צוות. אם תהיתם פעם למה שמות קבצים מסתיימים ב-"_Central" - זו הסיבה.
במקום לפתוח את דיאלוג מוניטור שיתוף העבודה כדי לבדוק מי הבעלים של מה, מודליסט יכול להפעיל תצוגת שיתוף עבודה ישירות בתצוגת תלת-ממד או תוכנית כדי לראות אותה צבועה על פני הגיאומטריה בפועל - שימושי לאיתור מהיר של אילו חלקים במודל נערכים כרגע באופן פעיל על ידי חברי צוות.
כאשר שמירה למודל מרכזי רצה לאט או שחבר צוות לא מצליח לקבל אישור לבקשת עריכה, מוניטור שיתוף העבודה הוא המקום הראשון לבדוק בו - הוא מציג בדיוק מי מחובר, מה הוא שאל, והאם המודל המרכזי עצמו נמצא תחת עומס כבד באותו רגע.