Teknisk arkitektur, Från logiska krav till fysisk infrastruktur
Huvudvarning, jag tittar ner på varningstablåerna i min viggen. Hydraulsystem 1 har slutat fungera. Som tur är har flygplanet två parallella system och är fortfarande fullt styrbart. Logiska krav har en teknisk lösningn.
Den tekniska arkitekturen med kraven mot den är detaljbeskrivningen av hur ett system ska implementeras. Det är instruktionen till den som ska skapa implementeringen.
Men att bara konstatera att "det ska finnas två system" räcker inte för ingenjören på ritbordet. Om båda hydraulsystemens rörledningar dras tätt intill varandra längs flygplanskroppen, kan en enda granatsplitter eller ett mekaniskt haveri slå ut båda systemen samtidigt (ett så kallat Common-Cause Failure). Den tekniska arkitekturen måste därför specificera den fysiska och logiska isoleringen: exakt hur rören ska dras via olika vägar, vilka oberoende pumpar som ska driva dem, och hur ventilerna ska fungera på komponentnivå för att garantera flygplanets luftvärdighet. I den digitala och händelsestyrda världen fungerar det på exakt samma sätt. När vi översätter ett logiskt säkerhetskrav (till exempel: "ett kritiskt larm måste alltid levereras och dess integritet garanteras") till teknisk arkitektur, använder vi OSI-modellen som vår ritning. Vi delar upp implementationen i en vertikal kedja för att isolera felkällor – från den högsta tjänstenivån ner till den fysiska hårdvaran och nätverksvägen.
Innehåll
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Logiskt arkitektur till fysisk kod
För att bygga in säkerhet från början (Safety & Security by Design) enligt ISO 61508 och NIS2, kan vi inte hoppa direkt från ett affärsbehov till att skriva kod eller sätta upp molnservrar. Vi måste ha en strukturerad nedbrytning.
I vårt ramverk använder vi Enterprise Architecture (ofta modellerat i ArchiMate) för att separera systemet i tre tydliga abstraktionsnivåer. Detta gör att vi kan byta ut teknik i botten utan att säkerheten i toppen spricker.
Logisk Arkitektur (Vad ska vi göra?)
Den logiska arkitekturen är helt teknikoberoende. Här definierar vi systemets rena funktioner och vilka säkerhetskrav som måste uppfyllas för att affärsmodellen ska överleva.
Fokus: Funktion och Informationsflöden.
Exempel: Vi måste kunna ta emot ett larm och vi måste garantera att larmet inte har muterats eller förvanskats under transporten.
Service-arkitektur (Det skyddande kontraktet)
Mellan det logiska kravet och den fysiska koden bygger vi ett servicelager. En tjänst (Service) fungerar som en svart låda och ett strikt kontrakt mot omvärlden. Den döljer komplexiteten i hur något görs, och lovar bara att det görs.
Fokus: Inkapsling och Gränssnitt (API:er).
Varför det är viktigt: Om ett säkerhetskrav säger att data måste verifieras, är det Tjänsten som bär det ansvaret. Genom att bygga vår arkitektur kring väldefinierade tjänster förhindrar vi att olika systemdelar trasslar in sig i varandras kod.
Teknisk Arkitektur (Hur bygger vi det?)
Först när den logiska funktionen och tjänstekontraktet är spikade, tittar vi på den fysiska implementationen. Det är här mjukvara, hårdvara, nätverk, enheter (Devices) och plattformar som Apache Kafka eller AWS kommer in i bilden.
Fokus: Infrastruktur, noder och exekveringsmiljöer.
OSI-tänket skapar Cybervärdighet
När vi mappar vår arkitektur mot den tekniska verkligheten använder vi OSI-modellen (Open Systems Interconnection) för att förstå exakt var våra risker finns – och var vi måste bygga in vår redundans.
Lager 1–4: Transport och Tillgänglighet (Infrastruktur)
I de lägre lagren (Fysiskt nätverk, Routing, TCP/IP) hanterar vi nätverksavbrott, avgrävda fiberkablar och DDoS-attacker. Här bygger vi säkerhet genom att duplicera nätverksvägar, till exempel genom att skicka ett kritiskt meddelande via både mobilt bredband (IP) och det gamla GSM-nätet (SMS).
Mål: Garantera att meddelandet kommer fram.
Lager 7: Applikationslogik och Dataintegritet (Safety)
Men traditionell IT-säkerhet stannar ofta vid nätverket. Problemet är att nätverket (Lager 1–4) inte har någon aning om vad datan betyder. Om en minnesläcka eller en mjukvarubugg i en mellanliggande kö (ett s.k. systematiskt fel) gör att datan tyst muterar, kommer nätverket troget att transportera fram det korrupta meddelandet.
Mål: Garantera att meddelandet är korrekt.
För att stoppa de systematiska felen – de farliga situationerna där data "vaknar som en jätteinsekt" – måste vi flytta upp vår säkerhetsarkitektur till OSI-lager 7 (Applikationslagret). Det är här vår Service-arkitektur implementerar teknisk diversitet och oberoende röstningsförfaranden (Voting).
Hög nivå: Tjänstearkitekturen (Services – OSI Lager 7)
Det högsta skiktet i arkitekturen handlar om applikationslogik och systemets rena funktioner, helt frikopplat från vilken hårdvara det körs på. Här definierar vi tjänster som har ett strikt kontrakt mot omvärlden – till exempel en Larmmottagare eller den kritiska Röstaren (Votern).
Det är på denna nivå, i applikationslagret (OSI-lager 7), som vi bygger in den logiska redundansen. Det är här Votern tar emot data från oberoende kanaler och utför en bit-för-bit-analys för att verifiera att informationen är korrekt innan ett beslut exekveras.
Mellannivå: Mjukvara och Plattform (Software)
Under tjänsterna ligger mjukvaruskiktet som realiserar logiken. För att uppnå sann motståndskraft måste den tekniska arkitekturen medvetet bryta mjukvaru-monokulturen. Om vi kör exakt samma kod och plattform på alla ställen, kommer ett dolt mjukvarufel (ett systematiskt fel) att sänka alla instanser samtidigt.
Därför specificerar arkitekturen teknisk diversitet i plattformslagret. Vi kan välja att köra en molnspecifik kö i en kanal, en lättviktig meddelandemäklare som NATS i en annan, och Apache Kafka i en tredje. I denna arkitektur fungerar Apache Kafka som systemets "svarta låda" – en oföränderlig, distribuerad händelselogg som skriver allt till disk med strikta kontrollsummor (CRC32). Detta ger oss temporal redundans; om en bearbetningskomponent kraschar kan den spola tillbaka Kafkas logg och bygga upp sitt interna tillstånd till exakt rätt punkt igen, utan att data går förlorad.
Låg nivå: Infrastruktur, Enhet och Nätverksväg (Device, Network & Path – OSI Lager 1–4)
Det lägsta skiktet är den fysiska infrastrukturen där mjukvaran exekveras. Här adresserar vi hårdvarufel, strömavbrott och leverantörsrisker genom fullständig infrastrukturell diversitet:
Enheter och Noder (Device/Nodes): Vi kapslar in våra mjukvarubussar i isolerade containers (t.ex. Kubernetes) och sprider ut dem över helt skilda fysiska miljöer – exempelvis en kanal i Microsoft Azure, en i Amazon Web Services (AWS) och en på en lokal server (On-premise) i ett privat datacenter.
Nätverk och Väg (Network & Path): Kommunikationsvägarna dubbleras på nätverks- och transportnivå. Vi förlitar oss inte på en enda internetlina, utan tvingar datatrafiken att gå via helt separerade fysiska vägar – exempelvis krypterad IP-trafik över fiber parallellt med en sekundär reservkanal som utnyttjar GSM-nätets robusta SMS-signalering.
1 Logisk arkitektur till teknisk OSI7
När piloten drar i spaken och varningslampan för Hydraulsystem 1 tänds, är det tack vare den tekniska arkitekturen som flygplanet förblir manövrerbart. Kraven på absolut tillgänglighet för flygstyrningen har lösts genom att rita upp två helt parallella hydraulsystem. Samtidigt har konstruktörerna gjort en kritikalitetsbedömning: om väderradarn slutar fungera är uppdraget försvårat, men flygplanet störtar inte. Radarn tillåts ha en lägre redundansnivå.
Detta är kärnan i steget där vi transformerar den logiska arkitekturen till en funktionell OSI-ritning. Det är här vi slutar prata om vad verksamheten behöver på en abstrakt nivå, och istället ritar upp instruktionen för hur systemet ska implementeras tekniskt – men fortfarande utan att låsa oss vid specifika mjukvaru- eller hårdvaruprodukter.
Processen: Från logiska krav till tekniska skikt
Målet med detta steg är dubbelt:
Identifiera rätt arkitekturmönster på rätt nivå i OSI-modellen baserat på de logiska kraven (tillgänglighet, integritet, konfidentialitet).
Omforma de logiska kraven till funktionella, tekniska krav riktade mot specifika OSI-lager.
Genom att mappa den logiska arkitekturen mot OSI-modellen kan vi tillämpa ingenjörsmässiga principer som isolering och diversitet på ett strukturerat sätt.
Lägre lager (OSI 1–4): Transport och fysisk väg
Om det logiska kravet handlar om ren tillgänglighet (att informationen måste komma fram oavsett fysiska avbrott), adresserar vi detta i de lägre lagren. Precis som de parallella hydraulrören dras via helt olika vägar i flygplanskroppen för att undvika att ett enskilt splitterskott klipper båda, designar vi nätverkslagret med vägdiversitet (Path Diversity).
Vi omformar det logiska kravet till ett tekniskt krav: Informationen ska transporteras parallellt över oberoende fysiska nätverk och medier (t.ex. IP-trafik via fiber kombinerat med SMS via GSM-nätets signalering).
Högre lager (OSI 7): Applikationslogik och systematiska fel
Det är när vi möter krav på dataintegritet och skydd mot systematiska fel (mjukvarubuggar eller dolda datamutationer) som vi måste lyfta arkitekturen till OSI-lager 7 (Applikationslagret). Infrastrukturen i de lägre lagren är blind för innehållet; en router bryr sig inte om en databuffert har korrumperat ett larmvärde, den skickar bara paketet vidare.
För att lösa detta på ett flygsäkert sätt transformerar vi det logiska kravet till en Triple Modular Redundancy (TMR)-arkitektur på applikationsnivå:
Fan-out på lager 7: Den inkommande logiska servicen dupliceras omedelbart till tre helt oberoende, isolerade beräkningskanaler.
Output Voting på lager 7: Innan ett beslut exekveras eller skickas vidare till ett externt system, måste kanalernas resultat passera en oberoende Voter (Röstare). Vi sätter ett strikt tekniskt krav på Quorum (konsensus): Minst 2 av 3 kanaler måste leverera ett bit-för-bit identiskt resultat för att den logiska grinden (Voter-gate) ska öppnas.
Resultatet: Ett kontrakt för implementationen
När detta steg är klart har vi en komplett ritning. Vi har inte bestämt om vi ska använda Apache Kafka, AWS eller en specifik SQL-databas ännu. Men vi har bestämt att systemet ska bestå av tre diversifierade kanaler och en röstningskomponent på applikationslagret, samt dubblerade kommunikationsvägar i transportlagret.
Vi har transformerat verksamhetens diffusa önskemål till stenhårda, mätbara instruktioner för systemutvecklare och infrastrukturtekniker. Vi har lagt grunden för systemets cybervärdighet.
För att hjälpa dig och dina läsare att laborera med hur olika logiska komponenter (som din kritiska larmhantering eller din sekundära statistikmodul) ska hanteras och mappas i detta steg, kan du använda interaktivitetsverktyget nedan. Här kan du testa hur en förändring i kritikalitetsnivå och riskbild direkt transformerar kraven och ritar om arkitekturen i OSI-lagren.
2. Dynamisk beskrivning av OSI 7
Att veta att flygplanet har två parallella hydraulsystem är en bra start (Steg 1). Men vad händer i det exakta ögonblicket som trycket faller i det primära systemet? Det krävs en dynamisk sekvens: En sensor upptäcker tryckfallet, en logisk krets isolerar läckan, och en ventil slår blixtsnabbt över till reservsystemet. Detta är inte en statisk ritning – det är ett dynamiskt beteende som sker i en absolut kritisk tidsföljd.
När vi ska beskriva hur vår säkra arkitektur på OSI-lager 7 (Applikationslagret) fungerar, räcker det inte med att visa vilka komponenter som finns. Vi måste beskriva hur data strömmar och hur komponenterna agerar dynamiskt. För att göra detta begripligt för utvecklare och granskare använder vi två centrala begrepp från tekniklagret i ArchiMate: Tekniska funktioner och Tekniska processer.
2.1. Tekniska funktioner – Vad mjukvaran gör internt
En teknisk funktion (Technology Function) representerar en automatiserad kapacitet eller beteende inuti en specifik mjukvarukomponent. Det är mjukvarans interna "muskler".
I vår säkerhetsarkitektur på OSI 7 definierar vi funktioner som är helt avgörande för systemets cybervärdighet:
Inbyggd integritetskontroll: Att verifiera en kontrollsumma (CRC32) på ett inkommande meddelande för att se att det inte muterats i en Kafka-buffert.
Korsvalidering (Quorum-kontroll): Algoritmen inuti kvalitetssäkrarna som jämför ledarens förslag bit-för-bit med det egna resultatet.
Ledarvals-algoritm: Logiken som avgör vilken kanal som för tillfället ska ha mandat att skicka utdata.
2.2. Tekniska processer – Hur flödet rör sig över tid
En teknisk process (Technology Process) är en sekvens av tekniska beteenden och funktioner som sker i en bestämd ordning, ofta triggade av en specifik händelse (Event). Det är systemets "nervsystem".
En typisk teknisk process för en Triple Modular Redundancy (TMR)-arkitektur på OSI 7 beskriver larmets hela livscykel:
Fan-out-sekvens (Event: Larm inkommit): Meddelandet dupliceras och skickas parallellt till de tre meddelandebussarna.
Parallell exekvering: De tre kanalerna kör sina interna beräkningsfunktioner isolerat från varandra.
Voteringssekvens: Ledaren distribuerar sitt förslag, kvalitetssäkrarna röstar, och röstningsgrinden (Voter-gate) fattar ett konsensusbeslut baserat på 2-av-3-logik.
2.3 Varför den dynamiska beskrivningen är kritisk för Safety
Varför kan vi inte hoppa över det här steget? Därför att det är i den dynamiska beskrivningen som vi kan modellera och bygga bort systemets farligaste tillstånd: timeouts, kapplöpningsproblem (race conditions) och delade meningar (split-brain).Genom att rita ut den tekniska processen ser vi exakt vad som händer om Kanal A drabbas av en nätverkslatens och missar sitt tidsfönster (Watermark). Processen måste då innehålla en dynamisk regel: Om Ledaren inte levererat ett förslag inom 50ms, initiera en teknisk funktion för att tvinga fram ett nytt ledarval. Genom att beskriva OSI 7 både strukturellt och dynamiskt ger vi utvecklarna en exakt specifikation över hur koden ska bete sig i kritiska situationer. Vi lämnar ingenting till slumpen.För att ge dig en direkt, visuell förståelse för skillnaden mellan processen (tidsflödet) och funktionerna (de interna mjukvaru-algoritmerna) på OSI-lager 7, kan du använda verktyget nedan. Prova att stega igenom processen manuellt för att se hur de tekniska funktionerna aktiveras i varje skede av larmets livscykel.
2.4. Informationskravens natur: Den dynamiska beskrivningen på OSI 7
När vi lämnar den logiska arkitekturen vet vi att viss information ska utbytas mellan systemen. Men det är först i den tekniska arkitekturen, när vi gör en dynamisk beskrivning av OSI-modellens lager 7 (Applikationslagret), som vi identifierar informationens sanna natur och hur den beter sig över tid.
I denna dynamiska analys måste vi skilja på om informationen fungerar som en transaktion eller ett tillstånd (saldo).
Transaktionen (Händelsen): Ett isolerat faktum i tiden. Exempel: "Patienten tryckte på larmknappen" eller "100 kr drogs från kontot".
Tillståndet (Saldot): Det aggregerade, ihågkomna resultatet av historiska händelser. Exempel: "Larmets nuvarande status är kvitterat" eller "Saldot på kontot är nu 500 kr".
Denna dynamiska distinktion ställer fundamentalt olika krav på hur vi därefter designar vår informationsbehandling. En transaktion kan oftast hanteras tillståndslöst (stateless) – systemet tar emot larmet, transformerar formatet och skickar det vidare. Ett tillstånd, däremot, kräver tillståndsbaserad bearbetning (stateful processing). För att beräkna ett saldo eller en status måste applikationen ha ett ofelbart minne av historiken och absoluta garantier för att ingen transaktion har räknats dubbelt (vilket vi såg var Kafkas svaga punkt).
3. Informationsmodellering med UML
Vi vet nu att vi skickar "Larmdata" och "Journalunderlag" mellan våra logiska komponenter. Men vad exakt innehåller "Larmdata"? Om vi inte definierar detta i detalj, kommer utvecklarna att gissa vilka fält som ska finnas i databasen, vilket kan leda till att GDPR-klassad information läcker in i okrypterade loggar.
Här lämnar vi den övergripande Enterprise-arkitekturen (ArchiMate) och går ner i mjukvaruarkitekturen med hjälp av UML (Unified Modeling Language). Vi skapar en formell informationsmodell där vi bryter ner varje dataobjekt i dess exakta, atomära beståndsdelar. För objektet Larmdata slår vi till exempel fast att det består av ett Larm_ID (UUID), en Tidstämpel (DateTime) och ett Patient_ID (Integer).
Dataklassificering på fältnivå
I klassdiagrammet kan vi flagga exakt vilka attribut som lyder under Patientdatalagen. Vi kan markera att attributet Sjukdomshistoria i klassen Journalunderlag kräver kryptering på fältnivå, medan Transport_ETA i klassen Transportstatus kan transporteras i klartext. Det eliminerar all tvetydighet för utvecklarna.
4. Fysisk realisering
Vi återvänder till flygplanet. Vi vet nu exakt att vi ska ha två hydraulsystem (Steg 1) och vi har definierat hur de dynamiskt ska ta över från varandra vid ett tryckfall (Steg 2). Men om vi köper båda hydraulpumparna från exakt samma tillverkningsbatch, och de innehåller samma mikroskopiska materialfel, kommer båda att brista exakt samtidigt. För att uppnå sann luftvärdighet måste vi välja olika leverantörer och fysiskt placera utrustningen i olika delar av flygplanskroppen
När vi bygger IT-system för samhällsviktiga funktioner gör vi exakt likadant. I det tredje steget transformerar vi vår logiska och dynamiska applikationsarkitektur till en stenhård fysisk infrastrukturritning. Det är här vi rör oss ner i botten av ArchiMates tekniklager och fattar besluten om vilka specifika plattformar systemet ska exekveras på.
Bryta monokulturen: Noder och Systemmjukvara
I den strukturvy vi nu ritar upp (som visualiseras med de gröna 3D-boxarna, Nodes, i ArchiMate) placerar vi ut våra isolerade exekveringsmiljöer. För att bygga bort risken för Common-Cause Failures – dolda fel som slår ut hela systemet samtidigt – måste vi designa medveten teknisk diversitet.
Om vi placerar alla tre röstningskanaler (Kanal A, B och C) i samma Kubernetes-kluster hos samma molnleverantör, har vi skapat en monokultur. En enda felaktig uppdatering av molnleverantören raderar hela vår TMR-arkitektur (Triple Modular Redundancy). Därför specificerar detta tredje steg den fysiska isoleringen:
Infrastrukturell diversitet (Var det körs): Vi definierar att Kanal A placeras i Microsoft Azure, Kanal B i Amazon Web Services (AWS) och Kanal C på en lokal server (On-premise).
Plattformsdiversitet (Vad det körs på): För våra meddelandebussar väljer vi olika teknologier. Kanske använder vi Azure Service Bus för Kanal A, NATS för Kanal B, och Apache Kafka för Kanal C. Genom att integrera Kafka säkerställer vi dessutom en oföränderlig, distribuerad händelselogg i botten som kan rädda oss vid ett totalt systemhaveri.
Tekniska processer – Hur flödet rör sig över tid
En teknisk process (Technology Process) är en sekvens av tekniska beteenden och funktioner som sker i en bestämd ordning, ofta triggade av en specifik händelse (Event). Det är systemets "nervsystem".
En typisk teknisk process för en Triple Modular Redundancy (TMR)-arkitektur på OSI 7 beskriver larmets hela livscykel:
Fan-out-sekvens (Event: Larm inkommit): Meddelandet dupliceras och skickas parallellt till de tre meddelandebussarna.
Parallell exekvering: De tre kanalerna kör sina interna beräkningsfunktioner isolerat från varandra.
Voteringssekvens: Ledaren distribuerar sitt förslag, kvalitetssäkrarna röstar, och röstningsgrinden (Voter-gate) fattar ett konsensusbeslut baserat på 2-av-3-logik.
Från OSI 7 till OSI 1–4
Det är i detta steg som applikationslagret (OSI 7) slutgiltigt förankras i infrastrukturen (OSI 1–4). Vi definierar hur noderna pratar med varandra rent fysiskt.
Istället för att rita logiska pilar ritar vi nu ut krypterade Site-to-Site VPN-tunnlar mellan AWS och vårt lokala datacenter. Vi specificerar brandväggsregler, routing och fysiska lagringsvolymer. Applikationslogiken som vi designade i Steg 2 ("Korsvalidering") paketeras i containers och injiceras i dessa noder. Vi har nu en komplett "rysk docka" där koden ligger i en container, som ligger i ett kluster, som ligger i en skyddad molnzon.
5. Mjukvaru- & informationsarkitektur
Vi är framme vid det sista steget i vår nedbrytningskedja. Om vi återvänder till vår flygmetafor för en sista gång, har vi nu bestämt att vi ska ha parallella hydraulsystem (Steg 1), vi vet exakt hur de växlar vid ett tryckfall (Steg 2), och vi har bestämt vilka fysiska pumpar vi ska köpa och i vilka zoner de ska monteras (Steg 3).
Men ingenjören som ska montera eller tillverka själva pumpen kan inte arbeta utifrån en övergripande systemskiss. Vi måste öppna pumphuset. Vi måste rita ut de exakta dimensionerna på cylindrarna, hur ventilerna rör sig mekaniskt på millimeternivå, och hur oljan strömmar internt.
Inom mjukvaru- och systemsäkerhet är det precis här som Enterprise Architecture (ArchiMate) lämnar över till Software Engineering. I detta fjärde steg öppnar vi våra containrar (våra AWS-, Azure- och On-premise-noder) och använder UML (Unified Modeling Language) för och rita upp källkodens och datastrukturernas exakta arkitektur. Här möts mjukvaruarkitektur och informationsarkitektur i en helt deterministisk modell innan en enda rad kod skrivs.
Komponentdiagram (Struktur)
Vi bryter ner våra tjänster till konkreta mjukvarukomponenter med strikta gränssnitt (Interfaces) och portar. I vårt röstningssystem (Voter) definierar vi komponenter som LarmReceiver, QuorumValidator, StateStoreConnector och Exekutor. Komponentdiagrammet visar exakt hur dessa moduler är inkapslade och hur de är beroende av varandra via "ball-and-socket"-gränssnitt. Detta säkerställer att vi kan skriva om koden i LarmReceiver (kanske byta från Java till Rust) så länge komponenten uppfyller sitt UML-kontrakt.
Sekvensdiagram (Dynamik)
Detta är det viktigaste verktyget för att beskriva tidsaspekten på OSI-lager 7. Sekvensdiagrammet ritar ut "livslinjerna" för våra objekt och visar det exakta meddelandeutbytet mellan dem över tid. Det är här vi i detalj specificerar hur vår Leader-Follower-logik fungerar mekaniskt:
LarmReceiver tar emot en händelse från Kafka.
LeaderNode skickar ett ValidateCommand till FollowerNode.
FollowerNode returnerar ett VotePayload.
QuorumValidator utvärderar resultatet.
Här ritar vi även ut våra tidsgränser (Timeouts) i form av explicita tidsvillkor. Om ett svar inte inkommit inom ett givet antal millisekunder, visar sekvensdiagrammet exakt vilken felhanteringsväg objektet ska ta.
Klassdiagram (Datastruktur)
En av de absolut största felkällorna i distribuerade system är att data muterar eller tolkas olika av olika komponenter. Det är här informationsarkitekturen säkras med UML.
Vi definierar stenhårda datamodeller för all information som flödar genom våra meddelandebussar (Kafka, NATS). Varje larm, varje röst och varje valideringsresultat modelleras som en klass med explicita attribut och datatyper (t.ex. LarmEvent med attribut som UUID, Timestamp, KritikalitetsNivå och Checksumma). Detta klassdiagram ligger till grund för de scheman (t.ex. Avro eller Protobuf) som tvingar Apache Kafka att fungera som en typ-säker, oföränderlig logg och förhindrar datamutationer.
Tillståndsdiagram / Statecharts (Beteende)
För funktionell säkerhet (IEC 61508) finns det ett absolut grundkrav: Ett säkerhetskritiskt system måste i varje givet ögonblick befinna sig i ett känt, deterministiskt tillstånd. Vi använder UML Tillståndsdiagram (State Machine Diagrams) för att mappa upp komponenten Voters hela inre liv.Komponenten tillåts aldrig att "gissa". Den rör sig strikt mellan väldefinierade tillstånd via specifika triggers och vaktvillkor (Guard Conditions):IDLE $\rightarrow$ (Trigger: Larm mottaget) $\rightarrow$ COLLECTING_VOTESCOLLECTING_VOTES $\rightarrow$ (Vaktvillkor: Quorum uppnått) $\rightarrow$ EXECUTINGCOLLECTING_VOTES $\rightarrow$ (Vaktvillkor: Timeout uppnådd) $\rightarrow$ FAILSAFE_ACTIVE
Varför UML är det definitiva vapnet mot det "kafkaeska" felet
När vi analyserade hur data kan förvandlas till en jätteinsekt i Apache Kafka berodde det på systematiska fel – fel i tanken, logiska buggar eller dolda kapplöpningsproblem i koden.
UML är verktyget som eliminerar dessa fel innan källkoden ens skrivs. Genom att tvinga fram en bit-för-bit-definition av klasser, sekvenser och tillstånd kan arkitekten matematiskt och logiskt verifiera systemets beteende. Vi kan simulera vad som händer om en korrupt bit matas in, eller om en nod dör mitt i en röstningsekvens. När utvecklaren väl sätter sig för att skriva koden i Java, Rust eller Go, fungerar UML-modellen som en exakt monteringsanvisning. Det finns inget utrymme för gissningar, tolkningar eller personlig kodstil. Resultatet blir ett mjukvaruskikt med absolut cybervärdighet.
För att ge dig och dina läsare en direkt, interaktiv förståelse för hur källkodens inre liv styrs upp i detta fjärde steg, kan du använda UML & Tillståndsutforskaren nedan. Prova att stega igenom tillståndsmaskinen för Gipsats centrala Voter-komponent för att se exakt hur objekten och tillstånden skiftar när ett systematiskt mjukvarufel injiceras i en av kanalerna.