TFM slik vi kjenner den fra TianDV og TIDA ble laget i en verden uten BIM, der hovedformålene var å knytte dokumentasjon-, tag/merking i tegning og fysisk merking i bygget sammen ved bruk av unike og «menneskelig lesbare» komponent ID'er (TFM). TFM benyttes altså til:
- Fysisk merking av komponenter i bygg med unike komponent ID'er (TFM)
- Dokumentasjon knyttet til de samme unike komponent ID'er
- De unike komponent ID'er skal fremgå i tegning.
Utfordringer ved TFM har vært at kodene i dokumentasjonssystemets tabeller ikke har vært linket til komponentene i tegning, og det er krevende å opprette og vedlikeholde ID kodene flere steder parallelt. Konsekvensen har gjerne vært at man avventet innlegging av kodene til «i seneste laget» og man har heller ingen garanti for at de kodene som er dokumentert er de samme som går igjen på tegning.
Dagens teknologi gir nye muligheter for å strømlinje-forme prosessene med å opprette og vedlikeholde TFM kodene. Med dRofus 2.0 er de linket sammen slik at det er mulig å vedlikeholde kodene ett sted og synkronisere dette mellom dokumentasjonssystemet og BIM (og derved tegning). Det er også større fleksibilitet mtp hvordan man setter sammen koden som skal fysisk merkes.
TFM er imidlertid ikke helt «harmonisert» med datamodellene i BIM.
Dagens TFM består av 3 elementer som settes sammen til en unik ID:
- Lokasjonskode
- Systemkode
- Komponent kode
Hvor «unik» TFM nummeret er avhenger av hvordan man har valgt å organisere dataene, men unik enten innenfor prosjekt, eiendom eller portefølje. dRofus garanterer unik i database. Dagens datastruktur er basert på en flat struktur med to entiteter
- Systemer
- Komponenter
Systemer må ikke ha komponenter, men komponenter må tilhøre et system.
Systemer i dagens TFM er egentlig bare en ren gruppering av komponenter og opprettes i systemgrupper basert på bygningsdelstabellen (p.t. iht NS 3451 2009). System koder benyttes i dag både som gruppering av komponenter som funksjonelt henger sammen (tekniske fag), men systemer benyttes også innimellom som rene type betegnelser, og da særlig innenfor kapittel 2. Både vegger, søyler, bjelker mv. får ofte et systemnummer benyttet som en type ID. For eksempel vil et «innerveggsystem» kunne hete +AA=242.001 og representere en type innervegg.
KomponentType kodene er to bokstaver foran et løpenummer som sier noe om hva en komponent er. I dagens TFM er imidlertid en komponent både en forekomst, medlem av system, en type og et produkt på en gang. Vi ser også at man bygger mye «menneskelig» logikk inn i løpenummer på komponent for å dekke behov som dagens datamodell ikke løser. For eksempel at man benyttet ulike nummerserier avhengig av hvilket system man tilhører i ventilasjon, eller hvilken kurs en elektrokomponent tilhører.
Det man i TFM kaller typeunikt angis med en T etter løpenummer. Da har man en komponent som er typeunik i system. I praksis betyr det bare at det er mer enn en instans i dette systemet som har denne koden (antall > 1), men dette er ikke i tråd med det man i prosjektene og BIM legger i en typebetegnelse.