Fi2xml version 1.3. Remiss

Transkript

1 Fi2xml version 1.3 Remiss

2 Innehållsförteckning FÖRORD BAKGRUND PROJEKTUPPLÄGG DELRAPPORTENS INNEHÅLL DOKUMENTHANTERING... 6 METADATA OCH BIFOGADE DOKUMENT... 6 LEVERANSSPECIFIKATIONER... 6 VÄRDELISTOR FÖR DOKUMENTKLASSER, HANDLINGSTYPER OCH STATUS MILJÖ OCH VAROR... 7 ENTITETEN BYGGVARA (FI2PRODUCT)... 7 ÖVERSTYRNING AV EGENSKAPSVÄRDEN... 7 FASTIGHETSMEDDELANDET DÖRRMILJÖER... 8 BEHOV... 8 DÖRREGENSKAPER... 8 LÅSSYSTEM ÄRENDEHANTERING PROCESSKARTOR RESURSMODELLEN UNDERHÅLLSPLANERING UNDERHÅLLSPLANERING I RESURSMODELLEN MÖTE KRING FI2XML 1.3, ÄRENDEHANTERING SLUTSATSER AVTAL SAMORDNING AV AVTALSVARIANTER PARTER OBJEKT KONTRAKT ÖVRIGA ÄNDRINGAR MODELLER MÅLNAMNRYMD (TARGET NAMESPACE) HANDBOK LITTERATURFÖRTECKNING Kapitel: Bakgrund

3 Fo rord Den senaste versionen av fi2xml-standarden, version 1.22, publicerades Sedan dess har behov av förändringar och tillägg på flera områden framkommit. Vid möte i tekniskt råd och styrelse hösten 2011 bestämdes att genomföra en förstudie kring frågan. Förstudien antogs i januari 2012, och man beslutade då att gå vidare med projektet och ta fram en ny version av standarden. Denna delrapport tillsammans med bilagor utgör remissunderlaget. De synpunkter och åsikter som kommer in under remisstiden kommer sedan att diskuteras och prövas för att utgöra underlag till det förslag som enligt plan levereras för slutremiss vecka 39. Slutligt antagande av den uppdaterade standarden beräknas till vecka 41. Delrapporten har författats av Daniel Enström, Informationsbyggarna, på uppdrag av Fi2:s tekniska råd. Frågor kring rapportens innehåll kan ställas på epost till de@informationsbyggarna.se. Daniel Enström Utredare Informationsbyggarna de@informationsbyggarna.se Jan-Anders Jönsson Projektledare Utvecklingsstrateg Fi2 Förvaltningsinformation jaj@akej.se 3Kapitel: Bakgrund

4 Inledning 1. Bakgrund Projektet fi2xml 1.3 omfattar fem fokusområden: dokumenthantering, miljö och varor, dörrmiljöer, ärendehantering och avtal. De olika områdenas förändringsbehov och historik skiljer sig stort; dokumenthantering och miljö tar avstamp i tidigare projekt där resultaten ska inkorporeras i fi2xml, avtalsområdet behöver en genomgång och strukturering, medan dörrmiljöer och ärendehantering är områden där föreningens medlemmar har efterfrågat åtgärder. Även frågan om målnamnrymd, target namespace, togs upp i förstudien. Att ge ett xml-schema en målnamnrymd innebär att man knyter tillämpningar av schemat hårdare till schemadefinitionen, och erbjuder en möjlighet för tolkande system att avgöra en xml-fils ursprung och giltighet. Den förstudie i projektet Fi2xml 1.3 som framlades för föreningens tekniska råd utgör tillsammans med en tidplan presenterad vid samma tillfälle projektdefinition för det fortsatta projektet. Vid genomgången av förstudien lades också till protokollet att området ärendehantering skall utredas ytterligare med särskild hänsyn till relationen ärende underhållsplanering, och att ingrepp i resursmodellen inte får hindra framtida utveckling och användning av modellens entiteter och relationer. 2. Projektupplägg Projektet följer på förstudieprojektet Fi2 nästa version förstudie som avrapporterades och föredrogs för tekniskt råd på möte den Projektrapporten tjänar också som projektdefinition för detta genomförandeprojekt, vilket beslutades på ovan nämnda möte i tekniskt råd och samma datum på styrelsemöte i Fi2. Projektet avrapporteras genom denna delrapport, som går ut till föreningens medlemmar för remiss, och en senare slutrapport med planerad levererans vecka 34 varefter en slutremissrunda tar vid som avslutas med ett slutligt antagande vecka 41. Denna kortfattade rapport och dess bilagor, samt uppdaterade xml-schemafiler och klass- och värdelistor utgör dokumentationen vid delrapporteringen. Här lämnas fördjupad information om de delar i förstudien där sådan saknats, principer för dokumentation och handbokstexter. Slutrapporten består av handboken i sin uppdaterade version, tillsammans med nya versioner av xml-scheman och klassoch värdelistor. 3. Delrapportens innehåll Delrapporten går igenom de fem fokusområdena och de ändringar som föreslås inom varje område. Bakgrunden till de flesta åtgärder finns beskrivet i detalj i förstudien, i denna rapport ges en kortfattad genomgång av åtgärderna, och de tekniska detaljerna specificeras i bilagor. Åtgärderna görs inom någon av delaktiviteterna modell, schema, klass- och värdelistor, meddelande och handboksinnehåll 4Kapitel: Bakgrund

5 Modeller Fi2xml baseras på sex modeller som beskriver olika områden inom fastighetsförvaltning översiktligt. De olika modellerna är avtalsmodellen, målmodellen, intressentmodellen, resursmodellen, fastighetsmodellen och modellen för programarbete. I förslaget till ny version av fi2xml föreslås två namnändringar för modeller och två helt nya modeller. Förslagen redovisas i detalj i bilaga 1. Fi2xml basschema Basschemat för fi2xml, fi2base, täcker alla basentiteter och komplexa strukturer som används i fi2xml. Rapporten föreslår ett antal ändringar som rör både entiteter och strukturer, och att basschemat får den nya versionen fi2xml 1.3. Ändringar i fi2base specificeras i bilaga 2. Klass- och värdelistor Ändringarna i fi2xml för med sig behov av ett antal nya klasslistor. De förslag som ställs i rapporten kring klasslistor är att sådana tas fram för att täcka uppkomna behov. För klasslistorna utformning lämnas förslag, men beslut måste inte kopplas till införandet av fi2xml version 1.3. Alla förslag till nya klasslistor redovisas i bilaga 3. Meddelanden Ändringar i Fi2:s publicerade meddelanden sker normalt i de intressegrupper som tagit fram meddelanden. Med denna rapport görs ett avsteg från den principen, då ändringar i fastighetsmeddelandet föreslås, vilka är nödvändiga för att möta de behov som ställs inom området miljö/vara. Ändringarna i fastighetsmeddelandet specificeras i bilaga 4. Handbok I delrapporten presenteras ett förslag till inriktning och upplägg för den uppdaterade handboken. En detaljerad disposition tillsammans med förslag på författare för de olika delarna lämnas i bilaga 5. 5Kapitel: Delrapportens innehåll

6 Genomgå ng 4. Dokumenthantering Metadata och bifogade dokument I förstudien identifierades behov av att kunna bifoga fysiska dokument till fi2xml:s entiteter, något som inte är möjligt i den gällande versionen av fi2xml. Det finns också begränsningar i vilken typ av metadata som kan skickas med en dokumentlänk. Vissa vanliga metadata-egenskaper finns som fasta element för dokumentlänken, andra saknas. Till metadataegenskaperna hör även dokumentrelationer, vilka saknas i fi2xml. Lösningen på dessa behov är att förändra typen dokumentlänk, fi2document_type. Typen fi2document_type Typen förändras på det sätt som föreslagits i förstudien. Förändringarna har två huvudsyften: att möjliggöra infogande av en fysisk fil som refereras och att kunna ange metadata för dokument. Det förstnämnda åstadkoms genom att en ny egenskap läggs till som kan hantera en fil kodad med det xml-vänliga formatet Base64. Metadata läggs till via en ny egenskap på typen som refererar till definitionen av metadata på sidan metadata.se. Förändringarna av typen dokumenteras i bilaga 1. Leveransspecifikationer Projektet leveransspecifikationer har pågått parallellt med framtagandet av nästa version av fi2xml. I uppdraget för detta projekt har ingått att undersöka eventuella krav som projektet leveransspecifikationer kan ställa på fi2xml. Projektet leveransspecifikationer har resulterat i ett schema för överföring av leveransspecifikationer som bygger på den befintliga versionen av fi2xml, och inga krav på förändringar i fi2xml har noterats. I nästa steg av leveransspecifikationsprojektet ska ett xml-meddelande för leveranser tas fram. Detta meddelande kan komma att fysiskt innehålla de filer som levereras. Ett sådant scenario täcks in av de förändringar som föreslås för den komplexa strukturen fi2document_type. På samma sätt kan hanteringen av metadata för levererade informationsmängder hanteras via den förändrade fi2document_type. Andra krav som projektet kan ställa på fi2xml har inte identifierats. Värdelistor för dokumentklasser, handlingstyper och status Värdelistorna togs fram i IT-Bygg och fastighet-projektet Information om dokument 2003, och har publicerats på webbplatsen metadata.se. Värdelistan dokumentklasser kan användas för att ange ett dokuments användning. Listan har två nivåer: grov och fin nivå (IT Bygg och fastighet, s. 24). Listorna för handlingstyper och status är platta i sin uppbyggnad. I uppdraget för denna rapport ingår att omvandla värdelistorna till fi2:s format för klass- och värdelistor. I samband med omvandlingen transformeringen av värdelistan dokumentklasser ändras den till att vara hierarkisk i sin uppbyggnad vilket möjliggjorts i den senaste versionen av fi2:s xml-struktur för klass- och värdelistor. 6Kapitel: Dokumenthantering

7 Listorna är publicerade på metadata.se och beskrivs där som värdelistor. I fi2xml betraktas listorna emellertid som klasslistor, dels för att värdelistebegreppet i fi2xml inte stämmer med definitionen i metadata.se, dels för att listorna beskriver klassificeringar av dokument. Transformeringen och resultatet presenteras utförligare i bilaga 2. Åtgärder inom området dokumenthantering - Förändring i strukturen fi2document_type för att hantera bifogade dokument - Förändring i strukturen fi2document_type för att hantera bifogade metadata - Transformering av värdelista för dokumentklasser från metadata.se till fi2xml - Transformering av värdelista för dokumentstatus från metadata.se till fi2xml - Transformering av värdelista för handlingstyp från metadata.se till fi2xml 5. Miljö och varor I förstudien beskrevs ett antal ändringar i fi2mxl som föreslogs i SBUF-projektet Gemensamt datakommunikationsformat för livscykelinformation. Ändringarna behövs för att möjliggöra överföring av information om byggvaror, för att kunna koppla byggvaror till utrymmen och för att kunna överföra aggregerade miljödata för byggnader, eller delar av byggnader. Entiteten byggvara (fi2product) Entiteten används för att föra över detaljerad miljödata och egenskaper för en byggvara. Entiteten följer standarden för fi2xml-objekt, med element för identiteter, systemidentiteter, klassificeringar och värden, dokument, processer och kompletterande information (Apparea). Därutöver har entiteten element för namn, beskrivning, tillverkare och bilder, samt ett antal miljörelaterade egenskaper som kemiskt innehåll, utsläpp, LCA-data och livscykelkostnad (LCC). Entiteten finns dokumenterad i bilaga 1. Byggvaran infogas i fi2xml genom att läggas till fastighetsmodellen. Förändringen dokumenteras i bilaga 2. Överstyrning av egenskapsvärden Byggvaran har en egenskap som inte stöds av den gällande versionen av fi2xml. En viss byggvara kan ha olika egenskaper beroende på var i en konstruktion den används. Till exempel kan plastmattor ha olika emissioner beroende på om de används i våtrum eller vanliga miljöer. För att lösa sådana problem skapas en ny typ som hanterar överstyrning av egenskapsvärden. Överstyrningen definierar den kontext där värdet ska ändras, och det ändrade värde egenskapen ska ha. Kontexten uttrycks via en klassreferens (fi2class_type), och värdet visas med typen fi2value_type. Typen kallas fi2override_type och dokumenteras i detalj i bilaga 1. Fastighetsmeddelandet Fastighetsmeddelandet påverkas indirekt av ändringarna ovan genom att de entiteter som meddelandet innehåller har fått ändrade element för dokument. Det finns också behov av att i fastighetsmeddelandet ange de överstyrda värden som förklaras i stycket ovan, och att beskriva ytskikt och deras koppling till konstruktionsdelar och utrymmen. 7Kapitel: Miljö och varor

8 Meddelandet innehåller en typ, fi2itemidtype, för interna referenser som används i vyerna för att länka vystrukturen till de fysiska objekt den beskriver. I en sådan länkning till ett objekt kan det vara aktuellt att ändra egenskapsvärden, varför ett nytt element med typen fi2override_type läggs till i strukturen. Ändringen dokumenteras i bilaga 3. För att kunna beskriva skärningar och ytskikt, och deras relationer till byggdelar och utrymmen skapas en ny struktur i fastighetsmeddelandet. Rotnoden för skärningar, fi2interfacelist, läggs till mellan vyer och dataobjekt. Med den nya strukturen går det att beskriva dels externa skärningar, d.v.s. skärningar mellan fasta delar och utrymmen, dels interna skärningar som är gränser mellan olika byggdelar. Ändringen dokumenteras i bilaga 3. Åtgärder inom området miljö/vara - Införandet av entiteten byggvara (fi2product) - Införandet av den komplexa strukturen fi2override_type - Införandet av överstyrning av egenskapsvärden i fastighetsmeddelandet - Införandet av en struktur för skärningar i fastighetsmeddelandet 6. Dörrmiljöer I förstudien lämnades några rekommendationer för området dörrmiljöer : att bilda en referensgrupp för området, att avvakta med åtgärder tills behov inom området har utretts och konkretiserats, samt att samordna området med andra liknande områden såsom fönster. Under våren har ett inledande seminarium om dörrmiljöer hållits, och samtal har förts med intressenter i branschen, vilket har gett en tillräcklig genomlysning av branschens behov och önskemål för att ge ett förslag till förändringar i fi2xml. Området kan delas upp i två delområden utefter behov av informationsöverföringar: dörrmiljöer och låssystem. Delområdena flätas dock samman och därför föreslås en ny modell som hanterar båda. Då båda delområdena rör säkerhetsfrågor i förvaltningen, både gällande intrång och passerkontroll, och utrymning och brandskydd, föreslås att den nya modellen får namnet säkerhetsmodellen. Behov De behov som har framkommit under arbetet med förstudien och i seminarier och samtal är att kunna skicka information om dörregenskaper mellan designverktyg och förvaltningssystem, att kunna skicka information om dörregenskaper till dörrtillverkare, och att skicka information om låssystem mellan låsverktyg, låssmeder/låstillverkare och fastighetssystem. Dörregenskaper Dörren representeras i den föreliggande versionen av fi2xml av entiteten byggdelskomponent. Dörren kan ha ett antal enkla egenskaper som mått, brand- och ljudklass, material eller öppningssätt. För sådana egenskaper kan fi2:s vanliga egenskapshantering användas, i kombination med en ny värdelista för dörregenskaper. Information om lås och annan beslagning måste dock beskrivas på annat sätt då samma dörr kan ha flera låsindivider och beslagningar, vars skilda egenskaper i sin tur behöver beskrivas. En lösning för detta är att använda entiteten byggdelskomponent även för olika beslag, lås och behör. Det finns en risk för otydlighet då objekt av samma typ ska använda olika värdelistor för att 8Kapitel: Dörrmiljöer

9 beskriva sina egenskaper. En annan lösning är att införa nya objekt för dörr, lås och beslagning. På så sätt kan tydligare kopplingar mellan objekttyper och värdelistor skapas. Både dörrar och lås har dessutom vissa egenskaper som skulle kunna betraktas som fasta, och sättas som fasta element för respektive entitet. I förslaget till ny modell för säkerhetsområdet nedan föreslås därför att nya entiteter skapas för dörr, lås och behör. Lås kan också ses som en typ av behör, med särskilda egenskaper i behörighetssystemet. Fysisk del Behörighetskontroll FysiskResurs.Byggvara Består av Lås (fi2lock) Ger access Accesskontroll (fi2authenticator) Består av Placerad i Verifierar Behör (fi2fitting) Har behör Dörr (fi2door) Nyckel (fi2key) Från/till Innehas av FysiskResurs.Utrymme/- system FysiskResurs.Brukare Ger access till Behörighet (fi2authorisation) Omfattar Figur 1 Förslag till säkerhetsmodell Många av dörrens egenskaper gäller även för öppningsbara fönster och andra öppningskompletteringar för passage. En frågeställning är därför om dörrentiteten bör vara generell för öppningskompletteringar och istället få en egenskap som beskriver vilken typ den utgör. Dörregenskaper finns beskrivna i flera olika system i branschen, och önskemål om att sammanjämka dessa listor har uttryckts i föreningen. Föreningen har därför initierat en förstudie för att ena dessa begrepp. Resultatet av förstudien kan komma att infogas i slutrapporten för projektet fi2xml 1.3. Förstudien bör betänka de problem som kan uppstå inom dörrområdet då flera discipliner ska sätta egenskaper på objekt. Ett sätt att klarlägga ansvarsområden kan vara att ange egenskapers disciplin i värdelistor. 9Kapitel: Dörrmiljöer

10 Låssystem Det viktigaste behovet av dataöverföring inom lås- och säkerhetsområdet är att kunna överföra information om nycklar, behörigheter och utrymmen. Flera fastighetssystem hanterar sådan information i dagsläget, men överföringsformat för informationen saknas vilket leder till att mycket tid läggs på dubbelinmatning av data. Det finns därför stora besparingsmöjligheter i en standardiserad dataöverföring genom fi2xml. För att stödja framtagningen av fi2-meddelanden inom låsområdet föreslås därför att ett antal nya objekt för beskrivning av låssystem tillförs fi2xml i en ny säkerhetsmodell. Modellen presenteras ovan. Låset är den mekaniska (eller elektromekaniska) delen av säkerhetssystemet. Låset kontrolleras av ett system för behörighetskontroll, som kan vara kombinationen cylinder nyckel, passerkort eller andra elektroniska nyckelformer, eller direkt identifiering av individer med fingeravtryck eller annan biometrisk data. I förslaget till säkerhetsmodell delas behörighetskontrollen upp i brukarens del nyckeln och den kontrollerande parten autentiseringen. Begreppet nyckel används här i en vidare bemärkelse för brukarens identifiering, såsom en fysisk nyckel, passerkort, en kod eller ett fingeravtryck. Autentiseringen utgörs i sin enklaste form av låscylindern. För kortlås, kodlås och mer avancerade lösningar finns en låscentral som kontrollerar behörighet och styr det fysiska låset. Från beställarens sida kan också finnas ett behov att skicka en uppställning av behörigheter till låskonsulten. För att hantera detta föreslås en ny entitet för behörighet, som länkar brukaren och utrymmet eller utrymmessystemet. Behörighetsentiteten får egenskaper för behörighetsnivåer och begränsningar. Åtgärder inom området dörrmiljöer - Införande av entiteten dörr (fi2door) - Införande av entiteten lås (fi2lock) - Införande av entiteten behör (fi2fitting) - Införande av entiteten nyckel (fi2key) - Införande av entiteten accesskontroll (fi2authenticator) - Införande av entiteten behörighet (fi2authorization) - Införande av en ny säkerhetsmodell - Införande av värdelista för dörregenskaper - Införande av värdelista för behörsegenskaper 7. Ärendehantering I förstudien lades särskilt fokus på det enskilda ärendets faser. Rekommendationerna var att införa en ny entitet för ärenden samt att skapa en klasslista för ärendens status. Vid genomgången inför projektstarten påpekades att området hänger nära samman med underhålls- och resursplanering, och att även dessa områden ska tas i beaktande i den fortsatta utredningen. Processkartor I fi2:s processkartor som togs fram i det ursprungliga projektet FI2002 finns ärendeområdet behandlat. Området är genomgånget i detalj för de processer som rör energideklarationer, men även för annan ärendehantering finns det god dokumentation. Process 21 beskriver allmänt tillhandahållande av fastighetsanknuten service, och i delprocessen 212 beskrivs hela ärendekedjan översiktligt. I processkartan initieras processen via en felanmälan eller önskemål från brukare, vilket sammanställs Kapitel: 10

11 i en felrapport eller beställning. Åtgärden planeras därefter utifrån serviceplan, mål med verksamheten och andra faktorer, och resulterar i en arbetsorder. Arbetsordern utförs och efter rapportering kontrolleras och avslutas ärendet. Eventuella avvikelser rapporteras tillbaka och kan leda till ytterligare arbetsorder. Resursmodellen Fi2:s resursmodell ger en möjlighet att systematiskt beskriva FM-verksamhetens aktiviteter, och dessas planerade och faktiska resursförbrukning. Modellen omfattar entiteterna verksamhetshändelse, verksamhetsområde, process, processinstans, metod, resurs, resursrecept, resursmängd och resursaktivitet. Den har ännu inte blivit prövad i ett verkligt projekt, och det finns därför möjligheter att göra genomgripande ändringar i modellen. Underhållsplanering Underhåll delas i fastighetslexikon upp i förebyggande och avhjälpande underhåll, där förebyggande underhåll sker innan funktionsfel upptäcks, och avhjälpande sker efter att funktionsfel upptäcks. Underhållsplaneringen består i att identifiera de nödvändiga underhållsåtgärderna och planera deras utförande i tid, samt att se till att beredskap finns att utföra avhjälpande, akut, underhåll när sådant krävs. Underhållsplanering är inte i sig en egen verksamhet utan snarare en aktivitet som sker inom ramarna för förvaltningsverksamheten. Planeringen ger också upphov till ett antal planerade aktiviteter. Underhållsplanering i resursmodellen Resursmodellen anger hur olika händelser eller åtgärder i verksamheten kan beskrivas. Underhållsplanen bör ta upp ett antal sådana åtgärder som kan förväntas behöva utföras under den period som planen omfattar. Den entitet som kopplar samman underhållsplanen med resursmodellen är Verksamhetshändelsen (fi2activityevent). Verksamhetshändelsen beskriver vilka processer och aktiviteter den består av, samt vilka resurser dessa tar i anspråk. Underhållsplanen talar om när i tiden dessa kan behöva utföras. Möte kring fi2xml 1.3, ärendehantering hölls ett möte kring ärendehanteringen i fi2xml, med deltagare från flera systemutvecklare och fastighetsägare. Syftet med mötet var att lämna synpunkter på tillämpning av resursmodellens entiteter och underelement med utgångspunkt från dagens användning vid drift, skötsel och underhåll samt ärendehantering. I diskussionen analyserades ärendehanteringens processer och det konstaterades att det finns behov av klassificering av ärenden. På mötet beslutades också att gå vidare med ärendehanteringen som en separat modell i fi2xml version 1.3. Slutsatser Som föreslagits i förstudien och på senare arbetsmöte skapas en ärendehanteringsmodell med en entitet för ärende. Sedan förstudien har behov av entiteter för arbetsorder och underhållsplanering lyfts, och dessa har infogats i ärendehanteringsmodellen. Ärendehanteringsmodellen Ärendehanteringsmodellen i fi2xml ska inte vara ett komplett flödesschema över de processer som ärendehantering omfattar, utan en specificering av de objekt och egenskaper som ska kunna skickas mellan system för att spegla ärendehanteringen i förvaltningsverksamheten. Den modell som Kapitel: Ärendehantering 11

12 föreslås är enkel och innehåller endast entiteterna ärende, arbetsorder och underhållsplan. Modellen länkar till resursmodellens verksamhetshändelse, som beskriver den åtgärd som planeras i ett ärende och specificeras i en arbetsorder. Uppkomna ärenden resulterar (vanligen) i att en arbetsorder skapas. Det sätt arbetsordern utförs på kan ansluta till eller uttryckas som en verksamhetshändelse. På samma sätt resulterar underhållsplanens planerade underhåll i ett antal arbetsorder, medan det akuta underhållet istället resulterar i ärenden som hanteras vidare. Hur åtgärderna i underhållsplanens planerade underhåll ska utföras definieras via verksamhetshändelsens uppdelning i aktiviteter, processer och resurser. Ärende (fi2case) Resulterar i Underhållsplanering (fi2maintenanceplan) Arbetsorder (fi2order) Resulterar i Utförs som Resurs.Verksamhetshändelse Definierar Figur 1 Förslag till ärendehanteringsmodell Entiteter i ärendehanteringsmodellen De nya entiteter som föreslås är ärende, arbetsorder och underhållsplanering. Ärendet har element för rapporterare och utförare, för olika datum, det objekt där arbete ska utföras, och för budget och kostnader för genomförandet. Arbetsordern har ett fåtal element för datum, objekt och adress. Varken ärendet eller arbetsordern har element för att beskriva det arbete som ska utföras, det uttrycks istället med entiteten verksamhetshändelse i resursmodellen, och bör kopplas ihop med ärendet i det meddelande som används för dataöverföringen. Underhållsplaneringen har utöver standardelement element för giltighetsdatum och det objekt planen gäller för. Modellens entiteter specificeras i detalj i bilaga 1. Åtgärder inom området ärendehantering - Införande av entiteten ärende (fi2case) - Införande av entiteten arbetsorder (fi2order) - Införande av entiteten underhållsplanering (fi2maintenanceplan) - Införande av ärendehanteringsmodell - Införande av klasslista för ärendetyp - Införande av klasslista för ärendestatus Kapitel: Ärendehantering 12

13 8. Avtal I förstudien påpekades att avtalsentiteterna i avtalsmodellen innehåller likartade egenskaper, men inte alltid med samma namn eller i samma ordning. Ett mål för förändringen i modellen är därför att samordna de olika avtalsvarianterna så att de som har liknande egenskaper har dessa ordnade på samma sätt. Detta har också medfört att hanteringen av parter och roller strukturerats om. Samordning av avtalsvarianter Basschemat fi2base har ändrats för att bäst lösa samordningen av avtalen. Förändringen baseras på att en huvudstruktur för avtalen skapas med nedanstående utseende. Inledning Parter Andra objekt Datum Texter och övrigt Figur 2 Huvudstruktur för avtalsentiteter Inledningen består av de vanliga sju egenskaperna ids, sysids, classes, values, documents, process och apparea, samt i förekommandefall även namn och beskrivning. Blocket Parter har en upprepningsbar platshållare för parter enligt den nya typen fi2party_type. För varje part ska en typ specificeras enligt en klasslista. Ett förslag på klasslista finns i bilaga 2. Andra objekt kan till exempel vara hyresobjekt för ett hyres- eller köpeavtal. Blocket med datum innehåller datum för överlåtelse, försäljning, anställning etc. Varje sådant datum är en egen namngiven egenskap. Flera av avtalsvarianterna innehåller också information om texter som ska ingå i avtalsskrivningen. Dessa texter anges i blocket Texter och övrigt tillsammans med övriga avtalsspecifika egenskaper. Varje text och övrigt värde är en egen namngiven egenskap. Parter För att kunna koppla parter till roller skapas ett nytt attribut för avtalsparter i alla avtalsvarianter. En ny typ skapas för att hantera kopplingarna. Lösningen gör det möjligt att ange alla parter i ett avtal på samma plats, och för varje part ange den roll eller de roller parten har i den relation som omfattas av avtalet. Roller uttrycks enligt en ny klasslista enligt ovan. Den nya typen beskrivs i detalj i bilaga 1. Figur 3 Den nya typen fi2party_type Kapitel: Avtal 13

14 Objekt Objektsattributen är hyresobjekt eller sålt/köpt fastighetsobjekt i förekommande fall. Båda attributen anges som strängvärden. Kontrakt Flera av avtalsvarianterna har i version 1.22 av fi2xml platshållare för kontrakt, med användning av typen fi2contract_type. Dessa platshållare har tagits bort då typen dels utgör en ofullständig beskrivning av avtalet, dels öppnar för möjligheten att ange olika värden för samma egenskap då vissa av typens attribut även finns angivna för avtalstyperna. Typen fi2contract_type har attribut för datum för undertecknande och kontraktsdatum, samt inblandade parter, dock utan hänvisning till partens roll i avtalsrelationen. Åtgärder inom området avtal - Införande av den nya typen fi2party_type för hantering av avtalsparter - Alla befintliga attribut för avtalsparter tas bort från avtalsentiteter - Ett nytt attribut för avtalsparter med typen fi2party_type införs - En klasslista för roller i avtalsrelationer skapas - Attribut i avtalsentiteter omflyttas enligt ovan - Kontraktsattribut med typen fi2contract_type tas bort Alla schemaförändringar finns dokumenterade i bilaga Övriga ändringar Modeller Modellerna utgör tillsammans med processkartorna grunden för fi2xml. I förslaget till ny version av fi2xml föreslås några ändringar i modellerna. För två av modellerna föreslås nya namn som bättre ska avspegla deras innehåll. En nytillkommen entitet, byggvaran, behöver läggas in i en modell, och en helt ny modell föreslås för att hantera ärendeområdet. Resursmodellen Resursmodellen föreslås byta namn till Insatsmodellen. Modellen beskriver information om den löpande resurshanteringen i förvaltningsverksamhetens aktiviteter och processer. Resursen är en del av området; tillsammans med aktiviteter och processer beskrivs de insatser som görs i förvaltningsverksamheten. Modellen för programarbete Modellen föreslås byta namn till Verksamhetsmodellen. Modellens entiteter används för att beskriva en verksamhet, vilket kan ligga till grund för programarbete, men även för andra aktiviteter. En mer generell beskrivning av området är därför verksamhet, och modellens namn skulle också följa principen för namngivning av de andra modellerna. Fastighetsmodellen I förslaget har en ny entitet tillkommit: byggvaran. Entiteten kan kopplas både till resursmodellen och till fastighetsmodellen. Resursmodellen har entiteten resurs, som beskriver alla typer av resurser i förvaltningsverksamheten såsom material, arbete eller maskiner. Resurser av typen material motsvarar eller pekar på en (generisk) byggvara. En möjlig placering av entiteten hade därför varit Kapitel: Övriga ändringar 14

15 i resursmodellen, med koppling till resursentiteten. Mot det talar att resursmodellen beskriver principen för insatser, eller deras planerade innehåll. Kunskap om den faktiska byggvaran tillkommer först i utförandefasen av en åtgärd. Om entiteten byggvara används för att beskriva även generiska byggvaror eller material blir placeringen i resursmodellen emellertid logisk. Fastighetsmodellen beskriver den fysiska miljö som representeras av fastigheten med tillhörande byggnadsverk och dess vidare uppdelning. Här är det entiteten byggdelskomponent som ansluter till byggvaran. Byggnadsverk består av byggdelar, som i sin tur delas upp i byggdelskomponenter. Dessa kan i sin tur bestå av andra byggdelskomponenter som i sin högsta upplösning motsvarar inbyggda byggvaror. Syftet med den nya entiteten är att utifrån förvaltningens behov beskriva byggvarans egenskaper, vilket stämmer överens med fastighetsmodellens syfte. Förslaget är därför att införa den nya entiteten byggvara i fastighetsmodellen, och skapa en koppling mellan byggvaran och byggdelskomponenten. Figur 4 Den förändrade fastighetsmodellen Ärendemodellen En ny ärendemodell skapas för att beskriva ärendeområdet. En genomgång av modellen och dess entiteter ges i kapitel 7 ovan. Målnamnrymd (Target Namespace) En namnrymd är en behållare för termer. Inom en namnrymd finns bara unika termer, men samma term kan definieras inom flera namnrymder. I xml används namnrymder för att ange elementnamnens tillhörighet, vilket är viktigt i hanteringen av xml-scheman. Att ange en målnamnrymd för ett xml-schema betyder att man bestämmer en fast identifiering för element i xml-filer som hänvisar till schemat. Det gör också att ett system som ska tolka en xml-fil säkert kan identifiera filens namn- Kapitel: Övriga ändringar 15

16 rymd och därmed använda det tolkningsförfarande som passar för filtypen. För fi2xml betyder det att ett tolkande system alltid kan avgöra huruvida en fil är en fi2xml-fil. Detta betyder också att ett tolkande system kan ange att en fil som inte anger rätt namnrymd kan anses vara ogiltig. Det finns dock inget tvång för det tolkande systemet att varken ta hänsyn till namnrymder eller att betrakta filer som saknar angiven namnrymd som ogiltiga. En målnamnrymd anges för ett schema genom att attributet targetnamespace för schemats rotelement anges till önskad namnrymd. Attributet targetnamespace hör samman med två andra attribut som styr hur element och attribut representeras i filer som följer schemat: elementformdefault och attributeformdefault. Dessa attribut styr huruvida element respektive attribut som inte finns på rotnivån måste specificeras med ett namnrymdsprefix. Det vanligaste sättet att hantera målnamnrymder och kvalificeringar är att ange en målnamnrymd för schemat, och att kräva kvalificering av element men inte av attribut. Övriga föreslagna åtgärder - Resursmodellen byter namn till insatsmodellen - Modellen för programarbete byter namn till verksamhetsmodellen - Entiteten Byggvara (fi2product) läggs till fastighetsmodellen - En ny modell för ärendehantering skapas som kallas Ärendemodellen - Fi2xml-scheman i version 1.3 kopplas till en målnamnrymd med beteckningen Handbok En ny version av handboken behöver tas fram, som dels speglar de förändringar som har gjorts i fi2xml, dels anpassar innehållet till de önskemål som har kommit från medlemmar och externa intressenter. Det har bland annat funnits synpunkter på att handboken innehåller för mycket teknik för den som vill sätta sig in i principerna för fi2xml, samtidigt som det från systemutvecklare har kommit synpunkter på att handboken inte är tillräckligt detaljerad i sin genomgång av fi2xml:s tekniska sida. Till nästa version av handboken föreslås därför en uppdelning i två delar: en del som översiktligt beskriver bakgrunden till, och nyttan med fi2xml, och en del som beskriver tekniken bakom fi2xml och som kan användas som referens vid teknisk implementering av formatet. Följande är ett förslag till disposition av handboken för fi2xml version 1.3: Introduktion till Fi2xml Modellbeskrivning Avtalsmodell Målmodell Intressentmodell Insatsmodell Fastighetsmodell Verksamhetsmodell Ärendehanteringsmodell Komplexa strukturer Kapitel: Handbok 16

17 Meddelandearkitektur Fi2xml rekommenderade klasslistor och värdelistor Förändringar från version 1.22 Regelverk för utveckling av Fi2xml Redovisning av Fi2Organisation med Tekniskt råd Redovisning av Fi2Certifiering Fi2Support Utbildning i Fi2 Index Ett utförligt förslag till disposition av handboken finns i bilaga Litteraturförteckning IT Bygg och fastighet. (u.d.). Information om dokument. Hämtat från Metadata.se: den 13 Februari 2012 Kapitel: Litteraturförteckning 17

18 Bilågor Följande bilagor finns: 1. Förändringar i fi2xml 2. Nya klasslistor 3. Förändringar i meddelanden 4. Disposition av Handboken för fi2xml version 1.3 Kapitel: Litteraturförteckning 18