Alla ingenjörer behöver veta vad de kan och vad de inte kan göra med sina data och de konsekvenser som detta kan ha för deras dagliga arbetsbelastning. De kan behöva veta hur mycket strukturellt upplägg som är inblandat och om ett visst arbetsflöde eller en följd av händelser måste följas för att systemet ska fungera som de vill. Ju mer en ingenjör måste tänka på datahantering, desto mer påverkar det deras designprocesser, deadlines och eventuellt deras budgetar.
Hur data lagras i en fil.
Det här är det enklaste att förklara. Den som någon gång använt en dator för att skapa något – en bild, ett kalkylblad eller en CAD-design – har sparat sin data i en diskret fil på sin lokala hårddisk.
Varje filtyp har sin egen unika datastruktur, som registrerar all information i ett format som bara den programvara som skapade den kan förstå. Därför kan alla med samma version av samma programvara som du öppna och redigera din fil. Proprietära filstrukturer kan också enkelt omformas för att extrahera nödvändig information (DWG-filformatet är det främsta exemplet).
”De flesta experter är överens om att datafiler är en extremt osäker metod för lagring av data,” menar Neil Cooke. ”Filer kan enkelt misslyckas, skadas eller skrivas över. Hantera filer med Utforskaren är en mardröm, särskilt när du försöker hitta den senaste versionen av en ritning som ska tillverkas eller om flera konstruktörer arbetar med samma projekt. Filer kopieras och skickas överallt och till slut vet ingen vem som har vad eller vilken kopia som är den senaste versionen. Därför har varje CAD-leverantör en egen produktdatahanterings- eller PDM-programvara som de kan debitera extra för.”
Hur data lagras i en PDM-databas.
Egentligen är den här formuleringen vilseledande, hävdar Cooke.
”Data lagras inte i en PDM-databas, den lagras fortfarande i filer på en filserver med alla inneboende problem som nämns ovan. Vad som lagras i PDM-databasen är data om din data, så kallade ”metadata”. Det är som att hålla igång ett ”Rolodex-” eller bibliotekskortsystem för att hålla reda på var filer finns, ungefär som en kort sammanfattning av vad varje fil innehåller. För att hitta en fil, konsulterar man i detta sitt indexkort för att hitta var filen är lagrad och sedan kopiera den till din lokala hårddisk. Detta är vad vi brukar kalla för att, ”man checkar ut filen” (som att man ”lånar” en bok i bilblioteket, för att använda samma bildspråk som tidigare i denna kontext).”
Relationsdatabaser används i alla PDM-system.
Alla PDM-databaser använder det som kallas för en relationsdatabas. Dessa databaser lagrar metadata i fasta tabeller med scheman och pekare som länkar ihop flera tabeller. Detta gör att data kan struktureras och kategoriseras för att bli indexeringsbart. Därmed kan datat sökas och manipuleras med hjälp av ett strukturerat ”frågespråk”, (SQL)-transaktioner, noterar Onshapes Neil Cook:
”För en CAD-fil kan en tabell ange vilken typ av fil den är, var den är lagrad, lista alla egna egenskaper och ha länkar till den sammansättning eller det projekt den tillhör. En enkel SQL-fråga kan extrahera all information om en fil och dess relationella hierarki i förhållande till alla andra filer i din databas.”
Det här betyder att det går fort att hitta filer, men för att kunna arbeta med dem måste man alltså ”checka ut” dem; lika med, få dem kopierade lokalt till hårddisken.
Håller vi fast vid vår biblioteksanalogi, blir en följd av att man checkar ut filen/”boken” att när en kopia av filen är utcheckad, är den inte längre tillgänglig. Man kan fortfarande se informationen på ”bibliotekskortet” och en representation av filen, men själva filen kan inte kopieras eller redigeras.
Utcheckade filer är låsta av PDM-systemet för att hindra andra från att kolla in dem, redigera dem och skriva över ändringar. Ingen kan arbeta på den utcheckade filen innan den är incheckad i PDM-systemet igen, och upplåst.
”Denna mekanism säkerställer att de som har checkat ut filer enkelt kan spåras, filer kan kontrolleras och ’konflikter’ mellan designteam kan undvikas. Men i praktiken blir detta därmed mer av ett hinder än en fördel. Detta då låsta filer kan hindra andra från att arbeta i projektet, eller avbryta sitt arbete tills dess att filerna är incheckade och upplåsta igen. Först då ”återuppstår” möjligheten att redigera filen igen. Detta tvingar fram ett seriellt arbetsflöde som orsakar flaskhalsar och onödiga förseningar. Ju större teamet och desto snabbare konstruktionsprocessen är, desto större blir problemet.
”Filer, en gång utcheckade, är inte under kontroll. De kan kopieras och skickas vidare, vilket utgör ett annat stort säkerhetshot och dessutom medföra risken för en leverantör att producera den felaktiga versionen av en part eller komponent,” skriver Cook.
Hur data lagras i en (aggregerad) ”Nollfils-databas”
Även den här formuleringen är vilseledande, tycker Neil Cook. Vissa CAD-system har infört en ”ny” typ av fillagringssystem. Namnen är flera, ”file-less-”, ”no file” eller ”zero file”-databaser. Slutanvändaren interagerar alltid med PDM-gränssnittet och ser aldrig de faktiska CAD-filerna. Filerna hämtas dock i bakgrunden när en användare vill arbeta med dem. Om man vet var man ska leta, hittas de dolda i ett dunkelt område på hårddisken. Även om dessa filer tekniskt kan benämnas ”cache”, så innehåller de fortfarande editeringsbara CAD-data och varje fil måste först hämtas innan CAD-systemet kan öppna dem. Denna typ av system används, som konstaterats ovan, på Dassault Systemes’ 3DEXPERIENCE-plattform.
Det finns fördelar med denna metod för datalagring, menar Cook:
”Först och främst finns det ett centralt fillager, där alla kan hämta de data de behöver utan att behöva oroa sig för var någon av filerna finns (samma som för ”vanligt” PDM).
För det andra är de cachade filerna tillräckligt dolda och förvrängda att de endast kan öppnas av det installerade CAD-systemet och därför inte kan mailas.”
MEN nackdelarna då? En är att det är svårt att hitta några verkliga fördelar för ingenjören, skriver Neil Cook:
”När en del behöver editeras, hämtas den lokalt på användarens hårddisk och är låst så att ingen annan kan redigera den. Låter bekant? Detta är precis som med data i ett filbaserat PDM-system. När en ändring har slutförts, skickas filen tillbaka till databasen (”spara och checka in”) vilket för en stor fil kan ta lite tid, medan filen kopieras tillbaka till servern över nätverket eller internet.
Jag kan förstå varför folk blir förvirrade och kämpar för att få grepp om skillnaderna.
Eftersom denna typ av databas är baserad på SQL, med rigida scheman som inte enkelt kan ändras, kräver den här typen av system, precis som vanlig PDM, periodiskt underhåll, med nedstängningar för att installera servicepaket och uppgraderingar.
Det här är i princip gammal teknik med en ny färgton.”
Hur data lagras i en icke-relationsdatabas.
Den slutliga typen av databasstruktur som Neil Cook diskuterar i sin artikel är den som han menar gör Onshape unikt i CAD-termer.
Onshape använder en dokumentorienterad databasmodell, som stöder olika former av data och helt flexibla scheman. Det är en högpresterande och distribuerad, icke-relationell databas som används i stora dataapplikationer och till andra bearbetningsuppgifter som innefattar data som inte passar bra i en rigid relationell modell. I stället för att använda tabeller och rader, som i relationsdatabaser, består en icke-relationell databasarkitektur av samlingar och dokument. Neil Cook skriver:
”Så vad då?,” hör jag någon invända. Mitt svar? ”Denna grundläggande skillnad är det som möjliggör realtidssamarbete, samtidig editering, snabb och säker delning, versionskontroll och effektivt release management. Ingen annan produktutvecklingsplattform kommer nära och det finns definitivt inga filer här.
Uttryckt i lekmannatermer betyder det att ett helt designteam kan arbeta på samma projekt, samma församling, samma part och till och med samma skiss om det behövs. På samma gång. Ingenting är låst. Alla designaktiviteter utförs parallellt; när förändringar görs, registreras alla åtgärder i databasen och uppdateras omedelbart vart de än används. Det finns ingen ”sparaknapp”, ingen in-/utcheckning, oavsiktliga överskrivningar och ingen behöver vänta på att någon annan ska avsluta sitt arbete innan du kan börja med ditt.”
”Inga CAD-data lämnar någonsin våra servrar.”
Detta gör det möjligt för team att samverka kring komplexa parter och assemblies utan att fysiskt behöva vara på samma plats. Eftersom varje designändring spelas in kan ”konflikter” lätt lösas. Det ena teamet kan experimentera så mycket som de vill, antingen på samma arbetsyta eller i sin egen filial, och ändå veta att eventuella fel eller dåliga beslut alltid kan ångras. Kort sagt är Cooks poäng att Onshape ger möjligheterna att ångra eller omdirigera:
”Att dela data med kollegor, leverantörer eller kunder är enkelt och säkert. Inga CAD-data lämnar någonsin våra servrar,” skriver han och fortsätter: ”Det är precis som med Google Dokument, du behöver bara ange en persons e-postadress, bestämma vy eller editera behörigheter och klicka på ”Dela-knappen”. Genom att klicka på länken e-post öppnas din design i en webbläsare eller en mobilenhet. Ingen programvara eller nedladdningar krävs. Detta gör det möjligt för konstruktionsteam att arbeta tillsammans var som helst och utforma ”reviews” som ska utföras i realtid på vilken enhet som helst. Alla arbetar på exakt samma dokument, inte olika kopior av data. Åtkomst är lika lätt återkallad som den är tillåten. Kraftfullt och tidsbesparande? Ja, och då har jag inte ens nämnt CAD…”
