En enda tagg förväntas bära hela anläggningen.

En processvattenpump har en leverantörstagg. Elprojekteringen ger den en annan referens. Automationen skapar ett PLC-namn. Driften benämner den efter tjänsten den utför. Underhållet tilldelar den ett anläggningsobjektsnummer. En byggnadsmodell lagrar en egen objektidentifierare.

Varje identifierare kan vara användbar lokalt. Problemet börjar när organisationen försöker göra en av dem styrande för alla ändamål.

Den valda taggen växer tills den innehåller anläggning, område, linje, funktion, utrustningstyp, löpnummer och kanske en leverantörsförkortning. Den ser informativ ut, men innebörden är skör.

Flytta utrustningen och platsangivelsen blir fel. Byt ut produkten och den serialiserade identiteten ändras. Organisera om produktionslinjen och den operativa sökvägen ändras. Översätt gränssnittet och det föredragna namnet ändras.

Objektet blev inte nödvändigtvis ett annat objekt varje gång. En av dess representationer förändrades.

En tagg kan vara praktisk. Den kan inte vara fullständig.

Svaret är inte en längre tagg. Det är en tydlig ansvarsfördelning mellan identitet, namn, strukturer, klassificeringar, relationer och livscykelsystem.

En pump. Flera giltiga svar.

Tänk dig en pump som cirkulerar processvatten i ett bageri. Svaret förändras med frågan.

Teckensträngarna är schematiska. Det viktiga är att varje värde har ett uttalat tillämpningsområde och en ansvarig informationsägare.

En sökväg förklarar tillhörighet. En graf förklarar relationer. En beteckning ger en styrd väg. Ingen av dem är själva objektet.

Ge varje modell rätt uppgift.

Ingen standard har misslyckats för att den inte kan göra allt. Problemen börjar när vi ber en standard att utföra en annan standards uppgift.

Rollen kan överleva anläggningsobjektet.

Uttrycket ”pumpen” döljer ofta två olika entiteter.

Den första är en beständig roll: processvattenpump 1 måste cirkulera vatten för denna del av produktionen. Den andra är ett fysiskt anläggningsobjekt: tillverkare X, modell Y, serienummer 12345, som för närvarande fyller rollen.

ISA-95 skiljer mellan logisk utrustning och fysiska anläggningsobjekt. Den logiska utrustningen kan bestå medan den fysiska enheten byts ut. De funktionsorienterade och produktorienterade strukturerna i IEC 81346 erbjuder en annan användbar åtskillnad mellan avsett syfte och realiserad konstruktion. Ett CMMS/EAM kan representera den funktionella positionen och det installerade anläggningsobjektet som olika poster.

Denna åtskillnad bevarar den historik som människor faktiskt behöver. Driften kan följa den bestående rollen. Underhållet kan följa varje produkt. Projekteringen kan följa relevanta strukturella förekomster. Den semantiska modellen kan klassificera och relatera entiteterna utan att låtsas att de är en och samma post.

Rollen kan överleva anläggningsobjektet. Posterna bör förklara båda.

Kanonisk betyder inte en enda huvudsträng.

Standarderna och systemen behöver kunna enas om vilka avsedda entiteter deras poster gäller. Det är den kanoniska identitetens uppgift.

Ingen standard som behandlas här föreskriver exakt denna mekanism. Det är ett arkitekturbeslut från anläggningsägaren: ett kontrollerat sätt att hålla flera styrande representationer samordnade utan att pressa ihop dem till en enda post.

Kanonisk identitet är inte ännu en mänsklig tagg och inte ännu ett försök att ersätta varje lokal identifierare. Det är en stabil, systemneutral referens som används för att koppla samman styrda representationer.

Informationsryggraden behöver inte kopiera varje arbetsorder, ritning eller tidsserievärde. Den behöver tillräcklig identitet, kontext och proveniens för att hitta den styrande källan.

Lagra innebörden centralt. Låt nyttolasten stanna i sitt styrande system.

Det är därför modellerna bör samordnas i stället för att slås samman. En Brick-entitet kan mappas mot en kanonisk entitet. En ISA-95-roll kan representeras som en annan entitet. En objektförekomst enligt IEC 81346 kan ge en styrd beteckning. Ett anläggningsobjekt i CMMS kan peka på den fysiska produkten. Likvärdighet bör endast hävdas när tillämpningsområdena verkligen överensstämmer.

En gemensam verklighet kräver inte en enda monolitisk modell.

Gränser är en del av informationsmodellen.

En omogen arkitektur väljer ett system och kallar det huvudsystem för allt. En mogen arkitektur anger vad varje modell äger, hur representationerna är länkade och vad som händer när de inte stämmer överens.

Testet är inte om varje system visar samma identifierare. Testet är om organisationen kan härleda varje representation till rätt entitet, förstå dess tillämpningsområde och spåra vem som har rätt att ändra den.

Be inte en beteckning att bli en ontologi. Be inte en ontologi att bli ett arbetsordersystem.

Standarderna behöver ingen vinnare. Arkitekturen behöver gränser.