BIM- og CAD‑modeller: versionshistorik i byggesager

I mange byggesager drejer tvisten sig om projektmaterialet. Var fejlen i tegningerne, da de blev udleveret? Blev projektet ændret efter aftale, eller uden? Hvem vidste hvad, og hvornår? I dag er tegningerne sjældent papir. De er digitale modeller i BIM- eller CAD-programmer, og modellerne har en historik, som kan besvare nogle af spørgsmålene. Denne artikel handler om, hvad den historik kan bære, og hvordan advokaten får fat i den.

Den bredere dokumentation i byggesager, som projektweb, mails og fotos, er beskrevet i Entreprisesager: projektweb, mails og fotodokumentation. Her handler det kun om selve modellerne.

Fire lag af historik

Historikken i et byggeprojekt ligger typisk i fire lag:

Filversioner. Hver gang en model gemmes eller uploades, kan der opstå en ny version på en fildeling eller i et projektrum.
Status og udgivelser. Mange projektrum skelner mellem arbejdsfiler, delte filer og udgivne filer. Overgangen fra én status til en anden er ofte logget med tidspunkt og bruger.
Ændringer inde i modellen. Nogle programmer registrerer, hvornår et element blev oprettet eller ændret, og af hvem. Andre gør ikke, eller kun når en bestemt funktion er slået til.
Koordinering og bemærkninger. Kollisionsrapporter, bemærkninger og opgaver, der sendes mellem rådgivere, fx i BCF-format, viser hvilke problemer der var kendt, og hvornår.

Det er sjældent, at alle fire lag findes i samme sag. Spørg tidligt, hvilke værktøjer projektet brugte.

Hvad historikken kan vise

Hvilken version af modellen der var gældende på et bestemt tidspunkt.
Om en tegning, der blev udleveret til udførelse, svarer til den model, der lå bag.
Hvornår et element blev ændret, og ofte fra hvilken konto.
At en kollision eller fejl var registreret og meddelt, før den blev bygget.
Hvilke modeller fra andre fagområder der var koblet på, da en beslutning blev truffet.

Hvad historikken ikke viser

Hvem der besluttede ændringen. En konto, der gemte filen, er ikke nødvendigvis den, der traf beslutningen. Ofte modelleres ændringer efter mundtlig aftale.
Hvad der blev aftalt. Modellen viser resultatet, ikke drøftelsen. Byggemødereferater og mails skal stadig bruges.
At en version blev set. At en fil var tilgængelig i projektrummet, betyder ikke, at modparten åbnede den. Nogle projektrum logger visninger og hentninger. Andre gør ikke.
Ændringer mellem to gemte versioner. Gemmes filen sjældent, er mellemtrinene væk.

Eksport sletter historik

En vigtig faldgrube er formatet. Når en model eksporteres til et åbent format som IFC, eller når tegninger udskrives til PDF, forsvinder meget af historikken. Elementernes ændringsdata, lag, skjulte objekter og koblinger til andre modeller følger ikke nødvendigvis med.

Det samme gælder, når en fil downloades fra et projektrum. Filen kan være den rigtige, men projektrummets oplysninger om upload, status og bruger følger ikke med filen. De ligger i projektrummet.

Derfor bør advokaten skelne mellem tre ting, når der bedes om materiale:

PDF-tegninger · Indhold: Det, der blev udleveret · Begrænsning: Ingen historik, ingen modeldata
Eksport, fx IFC · Indhold: Geometri og egenskaber · Begrænsning: Ofte uden ændringshistorik
Native filer med projektrummets log · Indhold: Model, versioner og status · Begrænsning: Kræver det rette program og version

Programmet og versionen tæller

Native modelfiler kan ofte kun åbnes med det program, de er lavet i, og nogle gange kun med en bestemt version eller nyere. Ældre filer kan blive opgraderet, når de åbnes i en ny version, og så er de ikke længere identiske med originalen.

Bed derfor om at få oplyst, hvilket program og hvilken version filerne er lavet i. Sørg for, at der arbejdes på kopier med hashværdier, så originalen er uændret. → Fremlæggelse af digitale beviser: formater og bilag

Når modellen ligger hos modparten

Ofte ejer bygherren projektrummet, mens rådgiveren har sine arbejdsfiler lokalt eller i sit eget system. Projektrummet kan lukke for adgang, når byggeriet er afleveret, eller når abonnementet udløber.

Det giver to opgaver. For det første at få klienten til at sikre sin egen adgang og sine egne eksporter med log, mens adgangen findes. For det andet at beskrive præcist, hvad modparten skal udlevere. En begæring om “tegningerne” er for upræcis. Beskriv i stedet:

de native modelfiler for de relevante fag og perioder,
projektrummets versions- og statuslog for de pågældende filer,
logs over udgivelser og meddelelser til entreprenører,
kollisionsrapporter og bemærkninger, der vedrører det omtvistede område.

→ Editionsbegæring om digitale beviser

Kan historikken ændres?

Modparten kan rejse tvivl om, at historikken er ægte. Svaret afhænger af, hvor den ligger. Oplysninger inde i en modelfil kan i princippet ændres af den, der har filen og de rette værktøjer. Det kan for eksempel være oplysninger om, hvornår et element blev oprettet. Logs i et projektrum, som ingen af parterne administrerer, er sværere at ændre, fordi de ligger hos en udbyder.

Det taler for at sammenholde kilderne. Svarer tidspunkterne i modelfilen til projektrummets upload, til mails med vedhæftede tegninger og til byggemødereferaterne? Hvis ja, står historikken stærkere. Hvis der er huller eller modsætninger, er det et spørgsmål for en sagkyndig, ikke noget, advokaten selv bør konkludere på. → Indsigelse mod et digitalt bevis’ ægthed

Versionshistorik i andre dokumenter

Mange af de samme principper gælder for kontrakter, beskrivelser og andre dokumenter i byggesagen, hvor sporede ændringer og versioner kan vise forhandlingsforløbet. → Versionshistorik: hvem ændrede kontraktudkastet?

Skønstemaet

Er historikken central, kan den indgå i et skøn sammen med det byggetekniske. Det kræver ofte en byggesagkyndig og en IT-sagkyndig, der arbejder hver for sig eller sammen. Mulige spørgsmål til den IT-sagkyndige:

Hvilke versioner af modellen findes for perioden, og hvornår blev de oprettet?
Svarer den udleverede tegning til den model, der var gældende på udleveringstidspunktet?
Er det omtvistede element ændret, hvornår og fra hvilken konto?
Er der tegn på, at filer eller logs er ændret efter tvistens opståen?

Den byggetekniske vurdering af, om løsningen var forsvarlig, hører til den byggesagkyndige. → Syn og skøn i IT-sager