Revit projekt verzióváltása

A Revit modellek verzióváltására (update) sok fajta módszer és munkafolyamat létezik.

A legegyszerűbb, ha csak megnyitjuk a modelleket az új verziójú szoftverrel és elmentjük. Ez kisebb projekteknél, kisebb szervezeteknél működőképes megoldás lehet, viszont nagyobb projektek esetében ennél kifinomultabb munkamódszerre van szükségünk.

Alternatíva lehet a Revit eTransmit kiegészítője, avagy az Autodesk Construction Cloud (régen BIM 360) beépített funkciói, amik már jobb megoldásokat kínálnak, de még mindig nem tökéletesek.

Egy szoftveres átállás során számunkra a fő cél az adatvesztés és az ebből eredő kockázatok csökkentése. 7 évvel ezelőtt kialakult egy munkamódszerünk, amely célja, hogy hogyan lehet a lehető legnagyobb biztonságot elérni Revit projektek átállása kapcsán, azóta ezt a munkafolyamatot számtalanszor újragondoltuk, finomhangoltuk, aktualizáltuk és automatizáltuk.

Mi is ennek a lényege?

Tapasztalataink szerint Revit update során az alábbi főbb pontokra érdemes figyelni:

• Teszteljünk

Az update előtt csináljunk részleges vagy teljes teszteket, hogy minél pontosabban lássuk, milyen hibák jöhetnek elő, amiket kezelnünk kell. Például előfordul, hogy olyan kritikus hibákat látunk egy-egy verzióban, ami miatt azt kompletten kihagyjuk amíg megoldásra nem kerülnek. (pl. aktuális Revit 2023 verzió)

• A verziókat léptessük egyesével

Ha több verziót léptetünk inkább egyesével léptessük, ez csökkenti a felmerülő hibák (pl. széteső elemek, törlődő kóták, károsodott modell) számát. Előfordul, hogy több verzió egyszerre léptetésénél rengeteg elemünk szétesik míg, ha verziónként léptetünk nem jelentkezik a hiba.

• Unload-oljuk a Revit Linkeket előtte

A verzió váltás előtt a Revit Link-eket Unload-oljuk. Ez azért szükséges mivel, ha a Linkek Open állapotban vannak, úgy egyfelől lassabb is a folyamat, mert az adott modellel együtt a linkelt modellek verzióját is lépteti a szoftver, viszont ez esetben nem ment rá, így minden alkalommal megteszi ahová az adott modell linkelésre került. Másfelől, ha nem Unload-oluk úgy növeljük az elveszített Host-ok és feliratok kockázatát (amennyiben az adott elemünk vagy feliratunk Host-ja nem a saját modellünkben, hanem egy Linkben van).

• Adminisztráljunk

Minden felmerülő problémát, hibaüzenetet, log fájlt adminisztráljunk. Ez azért fontos, mivel az update után érdemes átnéznünk vissza ellenőriznünk a régi és az új fájl közötti különbségeket és ezek segítenek azonosítani, hogy mit ellenőrizzünk. A Revit hibák észlelése során szinte mindig jelzi ezt számunkra, így ezek ellenőrzésével jó rálátásunk lehet a felmerülő problémákra.

• Archiváljunk és ellenőrizzünk

Archiváljunk előtte, és ellenőrizzünk utána. Ha kritikus hibákat találunk sokszor egyszerűbb a régi verzióban javítanunk, és újra update-elnünk. Előfordul, hogy egy elemben van egy hibaüzenet, ami nem kritikus, viszont az update során szétesik az elem. Ha az elem szerkesztő módjában egyszerűen csak elfogadjuk az üzenetet és rámentünk, akkor már nem feltétlen esik szét az elem. (érdekes információ ennek kapcsán, hogy Family szerkesztésnél hiába nyitjuk meg a szerkesztő ablakot fogadjuk el a hibaüzenetet és töltjük vissza a Family-t a projektbe, ezt valójában nem fogja még a Revit betölteni, mivel számára változatlan az elem. Amennyiben csinálunk egy változást úgy már felül fogja írni. Ennek egyik egyszerű módja, hogy lerakunk egy vonalat, amit vissza is törölhetünk, és úgy töltjük vissza az elemet, ezt már vátlozásként érzékeli a szoftver.)

• Ütemezzük az átállást

Egy projekt során más társcégek, alvállalkozók is használhatnak Revit-et. Ilyen esetekben praktikus a natív fájlokkal adatot cserélni. Amennyiben mi átállunk egy frissebb verzióra viszont a partnerünk nem, úgy számára a mi modellünk nem lesz linkelhető, számunkra pedig minden adatcsere esetében updatelnünk kell a modelljeiket. A megrendelővel szintén egyeztetendő az átállás, hiszen elképzelhető, hogy a BEP-ben, szerződésben rögzítve lett a verzió, illetve ő is használja a natív fájljainkat. Amennyiben nagy projektről és sok fájlról beszélünk ez az átállás napokat vehet igénybe egy komplett csapatnak is. Ez idő alatt a tervezők nem tudnak dolgozni, hisz a modellek egymásba vannak linkelve, csak teljes átállás után lehet újra használni a fájlokat. Ezen okokból kifolyólag az átállásokat érdemes estére időzíteni, míg nagy projekt esetében pedig hétvégére. Ezekből is látszódik, hogy egy ilyen átállás jelentős menedzsment munkát is rejt a háttérben.

• Használjunk azonos verziókat

Szintén egyeztetendő a pontos verzió szám (értsd alverzió is nem csak főverzió mint Revit 2022) is a projekt tagok között. Célszerű ezt egységesen kezelni, ugyanis akár az alverzió számok közötti különbségek is fájl instabilitást végső esetben károsodást, összeomlást okoznak. (ehhez elegendő lehet az is, ha nem is nálunk van a verzió különbség, csak egy kapott linkelt modell használói között) A károsodott (corrupt) modellek javítása rengeteg időt vesz igényben, jellemzően nehéz kideríteni mely elemek okozzák, így célszerű törekedni ezek elkerülésére. Ez a gyakorlatban azt okozza, hogy mikor átállunk egy új Revit főverzióra és egy új alverzióra azt egyeztetjük az összes partnerünkkel és ők is átállnak rá. Ez valójában egy láncreakciót indít be, ugyanis, ha ők dolgoznak másik projekten ezzel a fő verzióval, ahol másik alverzió van, akkor célszerű nekik is egyeztetni emiatt az adott másik projekt átállását is, hogy ott is megmaradjon az egységes verziószám (avagy nem váltanak és vállalják az ebből fakadó kockázatokat).

• Tervezzük meg a kommunikációnkat

Jellemzően nem elegendő értesíteni mindenkit, érdemes átgondolni az egyeztetés sorrendjét is. Előfordult, hogy egyeztettük a társtervezőkkel megegyeztünk egy időpontban és az adott megrendelő – aki akkortájt nem használta a natív modellt – nem engedélyezte, így meghiúsult az átállásunk. Ugyanakkor az is előfordulhat, hogy egy olyan társtervező akadályozza az átállást, akinek a munkarésze nagyon kicsi a teljes projekthez képest, csak esetleg ő egy nagyobb cég része, ahol a verziószámok nem változtahatóak.

A munkafolyamat

Az általunk javasolt munkafolyamat lényege nagyjából az alábbi képen látható:

Ez egy korábbi verziója a mostani folyamatunknak, azóta szinte a teljes munkamódszert sikerült automatizálnunk.

2022 október elején zajlott a STUDIO IN-EX egyik legnagyobb projektének átállása. Pár adat az átállásról:

• 230 natív Revit modell update-je
• 100 egyéb nem natív Revit állomány update-je (jellemzően ifc-ből generált natív állományok)
• 8 különböző cég, akik érintve voltak az átállásban
• 1,5 hónap tervezés és tesztelés előzte meg
• 70 munka óra az updattel, illetve 30 munkaóra az utólagos javításokkal

Szerző: Oláh Zsolt, BIM Stúdióvezető