LISA 26
BRIGADENS AI-BESLUTSMOTOR

Varför brigadnivå

En plutons drönargrupp ser 2–5 drönare över ett 2 km²-område i 30 minuter. Ett brigad-drönarnätverk ser 50–150 drönare över 500 km² i veckor. Skillnaden är inte bara skala — den är kvalitativ. Mönster framträder: samma konvoj kl 03:00 på Väg M05 tre nätter i rad. Samma spaningsdrönare vid rutnätskoordinat PA 1234 5678 varje eftermiddag innan artillerield. En enskild plutons data är brus. En brigads aggregerade data är underrättelse. Lisa 26 existerar för att transformera drönarsensordata till underrättelse på brigadnivå och pusha handlingsbara beslut ned till den pluton som behöver dem på under 60 sekunder.

Fyrnivåarkitektur

Dataflöde — nedifrån och upp

Varje drönare genererar data. En FPV med Jetson Orin Nano kör YOLOv8 vid 30 FPS och producerar detektionshändelser: bounding box, klass (fordon/person/drönare), konfidens (0–1), tidsstämpel, drönarens attityd, kameraparametrar. En Fischer 26 ISR-plattform producerar detsamma plus STANAG 4609 KLV-metadata i varje videobildruta. En UGV producerar LiDAR-punktmoln och hinderkartor. All data flödar uppåt genom MANET-meshen:

Drönare → Plutonsterminal (lokal COP, 2–5 drönare) → Kompanitaktisk (sammanslagna plutons-COP:er) → Bataljonsops (sammanslagna kompani-COP:er + resursallokering) → Brigadstab (full bild + mönsteranalys + extern underrättelse). Varje nivå tillför värde: plutonen avduplicerar sina egna detektioner, kompaniet korrelerar mellan plutoner, bataljonen identifierar mönster mellan kompanier, brigaden fusionerar med OSINT/HUMINT och genererar strategiska hotbedömningar.

Dataflöde — uppifrån och ned

Underrättelse flödar nedåt lika snabbt som detektioner flödar uppåt. Brigaden identifierar ett mönster: fiendens artilleribatteri omgrupperar var 6:e timme, alltid längs Väg E10. Denna bedömning pushas till alla bataljonsnoder. Bataljonen allokerar en Fischer 26 ISR-sortie för att övervaka Väg E10 under det förutspådda fönstret. Kompaniet tar emot Fischer 26-flödet och förpositionerar FPV-grupper. Plutonen tar emot L2-rekommendationen: "Fordonskonvoj förväntas vid rutnät PA 2345 6789, tidsfönster 02:00–04:00, rekommenderad bakhållsposition 300 m söder." Plutonchefen godkänner. FPV-gruppen är beredd. Total beslutsutbredningstid från brigadanalys till plutonberedskap: under 5 minuter via MANET-push.

Beslutsbefogenhet — ROE per nivå

Detektionsmatematik (bevisad)

Grunden: kamerabild → målposition på marken. Varje detektion följer samma pipeline oavsett nivå. Matematiken är deterministisk och verifierad i lisa26-proof.py (15 tester, alla godkända).

Ground Sampling Distance vid höjd h med brännvidd f, sensorbredd w_sensor och bildbredd w_image:

GSD = (h × w_sensor) / (f × w_image)

Vid 120 m AGL med Arducam IMX477 (bearbetat exempel; se fischer26e.html för nuvarande 300 m / 500–700 m doktrin) (6,287 mm sensorbredd, 6 mm lins, 4056 px): GSD = (120 × 0,006287) / (0,006 × 4056) = 3,1 cm/px. Ett fordon (4 m långt) spänner över 129 pixlar — väl över YOLOv8:s minimidetektionsstorlek på 32 px. Verifierat: python3 lisa26-proof.py test #2.

Pixel-till-mark-projektionen använder drönarens attityd (roll φ, pitch θ, yaw ψ) från EKF3 AHRS och kamerageometri för att beräkna MGRS-koordinaten för varje detektion. Utan GPS beror positionsnoggrannheten på AHRS-drift: ±50–200 m efter 10 minuter (domineras av gyrointegrationsfel). Med terrängmatchning mot förladdat ortofoto: ±10–30 m. Detta är tillräckligt för områdesmålsökning — FPV-piloten hanterar terminalprecision visuellt.

Fusionsmatematik — multidrönaravduplicering

När två drönare ser samma fordon från olika vinklar måste Lisa 26 känna igen det som ett mål, inte två. Fusionsalgoritmen använder rumtidsgating: om två detektioner från olika drönare ligger inom 50 m och 30 sekunder från varandra är de kandidatmatchningar. Konfidenssammanslagning följer Dempster-Shafer-bevisteorin:

C_fused = 1 - (1 - C₁)(1 - C₂)

Två oberoende detektioner vid 70 % konfidens vardera: C_fused = 1 − (0,3)(0,3) = 91 %. Tre detektioner vid 70 %: C_fused = 1 − (0,3)³ = 97,3 %. Det är därför fusion på brigadnivå betyder något: en pluton med en drönare får 70 % konfidens. En brigad med tre drönare som täcker överlappande sektorer får 97 %. Den matematiska säkerheten skalar med antalet oberoende observatörer.

Matematisk härledning — varför fyra nivåer, inte tre eller fem

Lisa 26:s fyrnivå-hierarki (Brigad → Bataljon → Kompani → Pluton) är inte en konvention ärvd från militär kommandostruktur. Den är resultatet av en bandbredd/latens/fan-out-optimering som bryter sönder annorlunda vid tre och fem nivåer. Detta avsnitt härleder varför fyra är rätt antal givet Fischer 26:s MANET-meschkarakteristik, förväntat brigad-drönarantal och 60-sekunders beslutscykelmål.

Steg 1 — bandbreddsbegränsningen

Silvus StreamCaster MANET-radioer bär typisk aggregerad genomströmning på 15 Mbps per nod på 300 MHz-bandet under måttliga elektroniska interferensförhållanden (datablad: upp till 34 Mbps i rent spektrum, nedräknat för realistisk brusmiljö). Varje drönare genererar följande kontinuerliga dataström:

FPV-drönare detektionshändelser:
  Storlek per händelse:  ~1 KB  (JSON: klass, konf, bbox, attityd, tidsstämpel, CoT XML)
  Händelsetakt:          ~5 händelser/s  (YOLOv8 vid 30 FPS, ~15 % bildrutor innehåller detektion)
  Kontinuerligt utflöde: ~5 KB/s = 40 kbps per drönare

Fischer 26 ISR-ström:
  KLV-metadatapaket:     ~2 KB per bildruta × 30 FPS = 60 KB/s = 480 kbps
  Komprimerad H.265-video (valfritt, brigadströmning): ~2 Mbps

UGV-sensorström:
  LiDAR-punktmoln (nedsamplat): ~200 kbps

Brigadens förväntade drönarinventering (från FSG-A:s referensarkitektur):
  FPV:           40–60  @ 40 kbps var   = 1,6–2,4 Mbps aggregerade händelser
  Fischer 26:    6–10   @ 480 kbps var  = 2,9–4,8 Mbps aggregerade metadata
                        + 6–10 × 2 Mbps video = 12–20 Mbps om alla strömmas
  UGV:           4–8    @ 200 kbps var  = 0,8–1,6 Mbps
  
Rå aggregat om varje drönare strömmar till en brigadnod:
  Endast händelser: 5,3–8,8 Mbps  (väl inom en Silvus-länk)
  Händelser + all video: 17–25 Mbps  (överstiger enkellänkskapacitet)

Nyckelobservation: det råa aggregatet passar om brigaden bara tar emot detektionshändelser och selektivt hämtar video på begäran. En enkel-nivå-arkitektur (alla drönare → brigad) är bandbreddsgenomförbar för händelser. En enkel-nivå-arkitektur med all video är INTE det — den överstiger per-länk-kapaciteten.

Steg 2 — latensbegränsningen

Silvus MANET:s reläradiohoppen har ~8 ms latens per hopp vid 300 MHz (uppmätt från datablad + protokolloverhead). 60-sekunders brigadbeslutscykelmålet allokerar latensbudget enligt följande:

Latensbudget (drönardetektion → pluton tar emot L2-rekommendation):
  Sensor → FPV-bearbetning (YOLOv8 + pixel→MGRS):    50 ms
  MANET uppåttransit (drönare → brigad):             N_hopp_upp × 8 ms
  Brigadfusion + mönsteranalys:                      200 ms (PostgreSQL + Python)
  MANET nedåttransit (brigad → pluton):              N_hopp_ned × 8 ms
  Plutonterminalrendering:                           50 ms
  Människlig respons (läs, besluta, tryck knapp):    2000 ms (median i strid)
  Totalt:                                            2300 ms + 16 × N_hopp_per_riktning

För 60-sekunderscykelmålet måste latensen vara väl under 60 000 ms. Men UX-kravet är strängare: COP-uppdateringar måste kännas "omedelbara" för operatören, vilket publicerad HCI-forskning (Nielsen 1993, Card m.fl. 1991) placerar vid < 1 s för kontinuerlig uppmärksamhet. Budgeten för MANET-transit (upp + ned) är därför ~500 ms → maximalt 62 hopp. I praktiken med brigadskalig topologi är 8 hopp per riktning redan en värsta-fall-designpunkt.

Steg 3 — fan-out-begränsning per nivå

En Silvus-nod kan samtidigt upprätthålla kvalitets-MANET-länkar med ungefär 8–12 peers innan per-länk-genomströmningen degraderas på grund av tidsfackskonflikt (uppmätt degraderingsmönster från publicerat Silvus-testdata: 3 dB SINR-fall per extra peer ovan 12 i tät topologi). Med 4–8 optimala peers per nod är maximal fan-out per nivå ungefär 8×.

Fan-out-geometri:
  Om brigad = 1 nod med fan-out 8:
    1 nivå under:      8 noder   (passar ~8 bataljonsdrönarhubbar)
    2 nivåer under:    64 noder  (passar ~64 kompanihubbar)
    3 nivåer under:    512 noder (passar 100+ drönare + 100+ markterminaler)

Trenivå-alternativ (Brigad → Bataljon → Pluton):
  8 bataljoner × 8 plutoner = 64 plutonsterminaler
  64 plutoner × 2–5 drönare = 128–320 drönare
  ✓ Passar förväntad brigaddrönarinventering
  ✗ Bataljon blir flaskhals: 64 terminaler × 5 drönare × 40 kbps = 12,8 Mbps per bataljonsnod
    → överstiger 15 Mbps Silvus-aggregat i praktiken med annan trafik
  ✗ Varje pluton-till-bataljon-hopp = 1, varje bataljon-till-brigad-hopp = 1 = 2 hopp totalt
    → tight latens OK men bräcklighet: ett bataljonslänkfel isolerar 8 plutoner

Femnivå-alternativ (Brigad → Division → Bataljon → Kompani → Pluton):
  Varje nivås fan-out behöver bara vara 4 för att nå samma terminalantal
  ✗ Varje extra nivå adderar 16 ms round-trip-latens
  ✗ Extra nod betyder extra hårdvara att anskaffa, driva, transportera, underhålla
  ✗ Divisionsnivå finns inte i svensk brigadstruktur — skulle behöva uppfinnas

Fyrnivå-alternativ (Brigad → Bataljon → Kompani → Pluton):
  Brigad fan-out: 3–5 bataljoner
  Bataljon fan-out: 3–5 kompanier
  Kompani fan-out: 3–5 plutoner
  Pluton fan-out: 2–5 drönare + operatörsplattor
  ✓ Varje nod bär 3–5 × (40–200) kbps = 0,1–1 Mbps aggregat — väl inom 15 Mbps
  ✓ 3 MANET-hopp totalt = 24 ms latens — väl inom 500 ms-budgeten
  ✓ Matchar svensk brigadorganisation exakt
  ✓ Kompanifel isolerar bara 3–5 plutoner, inte 8

Steg 4 — varför 4 nivåer vinner över 3 och 5

Trenivå-designen misslyckas på bandbredd per enskild nod (bataljonsaggregatorn överlastas med direkt plutonsfan-in). Femnivå-designen misslyckas på onödig latens och organisatorisk missmatchning. Fyrnivå-designen klarar alla tre begränsningar — bandbredd per nod, total latens, organisatorisk anpassning — med marginal. Detta är inget godtyckligt val; att ändra någon av de tre begränsningarna (högre per-nod-bandbredd, lösare latens, annan organisation) skulle flytta optimumet, och härledningen gör detta beroende explicit.

Bearbetat exempel 1 — brigadkonfidens skalar med observatörsantal

Dempster-Shafer-fusionsformeln som visades ovan hävdar att fusion på brigadnivå av tre 70 %-observationer producerar 97,3 % konfidens. Här är den fullständiga numeriska härledningen och den operativa implikationen:

Enskild pluton, en drönare, ser fordon vid 70 % konfidens:
  C = 0,70
  → L2-tröskeln är 85 % → INGEN strike-rekommendation utfärdas.
  Plutonchef ser "troligt" fordon, beslutar med magkänsla.

Fusion på brigadnivå, tre drönare ser samma fordon vid 70 % var:
  C_fused = 1 − (1 − 0,70) × (1 − 0,70) × (1 − 0,70)
          = 1 − 0,3 × 0,3 × 0,3
          = 1 − 0,027
          = 0,973 = 97,3 %
  → L2-tröskel passerad → STRIKE-REKOMMENDATION utfärdas till närmaste FPV-grupp.
  Plutonchef ser "nästan-säkert" fordon, beslutar med hög konfidens.

Fusion på brigadnivå, fem drönare vid 70 % var:
  C_fused = 1 − 0,3^5 = 1 − 0,00243 = 0,9976 = 99,76 %
  → L2-tröskel passerad med god marginal.
  → Avtagande avkastning: 5 drönare är bara 0,5 procentenheter bättre än 3.
  → Operativ slutsats: 3 överlappande observationer är knät på kurvan.

Detta är den matematiska motiveringen för ISR-täckningsplanering på brigadnivå. Lisa 26:s täckningsplanerare (se lisa26-coverage-strategies.html) tilldelar explicit 3+ oberoende observatörer per högprioriterat målområde för att passera 85 %-L2-tröskeln med marginal, snarare än att förlita sig på enskilda drönares 70 %-observationer som tvingar plutonchefen till manuella bedömningar.

Bearbetat exempel 2 — brigadtäckningsområde vs plutonstäckningsområde

En enskild FPV-pluton täcker effektivt ungefär 2 km² i 30 minuter per sortie (begränsat av drönarens batteri + operatörens kognitiva kapacitet). Ett brigad-drönarnätverk med 60 FPV:er och 8 Fischer 26 i skift täcker brigadens fulla operationsområde kontinuerligt:

Plutontäckning:
  A_pluton = 2 km² × (30 min / 240 min skift) × (1 drönargrupp) = 0,25 km² × timskift
  → pluton "ser" 0,25 km² vid vilken tidpunkt som helst; sektor uppdateras var 4:e timme

Brigadtäckning (samtidig drift):
  Fischer 26 persistent ISR: 8 drönare × 100 km² täckningsområde × 2 h varaktighet
    = 1 600 km² × timme per 2-timmarsfönster
    = 800 km² kontinuerlig genomsnittlig täckning
  FPV reaktiv täckning: 60 drönare × 2 km² × ~25 % tillgänglighet
    = 30 km² kontinuerlig genomsnittlig täckning
  
  A_brigad = 830 km² kontinuerligt, uppdaterat minut för minut av ISR-orbiter
  
Förhållande: A_brigad / A_pluton = 830 / 0,25 = 3320×

Brigadtäckning är inte 10× en pluton — den är 3 000× vid varje given tidpunkt och, avgörande, kontinuerlig snarare än intermittent. Det är därför mönsteranalys (samma konvoj kl 03:00 tre nätter i rad) bara framträder på brigadskala: en pluton ser sitt 2 km²-område i 30 minuter en gång, kan inte upptäcka mönster; en brigad ser samma område var 5:e minut i 72 timmar och mönstret är statistiskt detekterbart inom 3 förekomster.

Verifieringskod — nivåbandbredd och fusionskonfidens

SILVUS_AGGREGATE_MBPS = 15
HOP_LATENCY_MS = 8
L2_CONFIDENCE_THRESHOLD = 0.85

def tier_bandwidth_load(drone_count, per_drone_kbps):
    """Return aggregate Mbps load on a tier node."""
    return drone_count * per_drone_kbps / 1000.0

def brigade_fused_confidence(single_source_confidences):
    """Dempster-Shafer fusion: C_fused = 1 - prod(1 - C_i)."""
    product = 1.0
    for c in single_source_confidences:
        product *= (1.0 - c)
    return 1.0 - product

def minimum_observers_for_l2(per_source_confidence, threshold=L2_CONFIDENCE_THRESHOLD):
    """Find minimum number of independent sources needed to cross L2 threshold."""
    n = 0
    fused = 0.0
    while fused < threshold and n < 10:
        n += 1
        fused = 1.0 - (1.0 - per_source_confidence) ** n
    return n if fused >= threshold else -1

# Reproduce bandwidth check for 4-tier design
company_platoons = 4
platoon_drones = 5
event_kbps = 40
load_per_company = tier_bandwidth_load(company_platoons * platoon_drones, event_kbps)
print(f"Company tier load: {load_per_company:.2f} Mbps  (budget: {SILVUS_AGGREGATE_MBPS})")
# Expected: ~0.8 Mbps — plenty of headroom

# Reproduce fusion scaling
for n in [1, 2, 3, 4, 5]:
    c = brigade_fused_confidence([0.70] * n)
    print(f"{n} sources at 70%: fused = {c*100:.2f}%")

# Minimum observers for L2 at different single-source quality levels
for single_c in [0.50, 0.60, 0.70, 0.80]:
    n = minimum_observers_for_l2(single_c)
    print(f"Single conf {single_c:.2f}: need {n} observers to cross 85%")

# Latency budget check
for hops in [2, 3, 4, 5]:
    round_trip_ms = 2 * hops * HOP_LATENCY_MS
    print(f"{hops}-tier round-trip: {round_trip_ms} ms")

Varför denna arkitekturhärledning är operativt viktig

Fyra operativa beslut beror på att nivåarkitekturen härleds från första principer snarare än antas. För det första anskaffningsdimensionering: den totala Lisa 26-brigadutrullningens kostnad (~45 000–80 000 €) domineras av antalet hårdvarunoder per nivå. En chef som överväger att "lägga till en femte nivå" måste se härledningen som visar att den femte nivån adderar kostnad utan bandbredds- eller latensfördel. En chef som överväger att "kollapsa till tre nivåer för att spara hårdvara" måste se bandbreddsanalysen som visar att bataljonsaggregatornoder överlastas vid rimlig drönarinventering.

För det andra felanalys: fyrnivå-designens fan-out-geometri innebär att förlust av en enskild bataljonslänk isolerar 3–5 kompanier (var och en med 3–5 plutoner), inte 8+ plutoner som i en trenivå-design. Detta betyder något för stridsskadefriktion: fiendens artilleri som träffar bataljonens MANET-nod avaktiverar 15–25 plutoner i en trenivå-design men bara 9–15 plutoner i en fyrnivå-design. Fyrnivå-designen har bredare redundansvägar (varje pluton har flera kompanipeers, varje kompani har flera bataljonspeers) till priset av ett extra hopp.

För det tredje EW-motståndskraft: bandbreddsanalysen i Steg 1 antog rent spektrum. Under aktiv störning sjunker Silvus-genomströmning till kanske 5 Mbps per nod (publicerad Silvus-testdata under realistiska EW-förhållanden). Fyrnivå-designen passar fortfarande eftersom per-nivå-lasten bara är 0,1–1 Mbps, men en trenivå-designs bataljonsnod överstiger den degraderade 5 Mbps-budgeten och misslyckas helt. Detta är inte en teoretisk oro — det är därför FSG-A valde fyra nivåer specifikt för nordiska operationer där rysk EW är det dimensionerande hotet.

För det fjärde skalning bortom en enskild brigad: härledningen visar att varje extra nivå adderar 16 ms round-trip-latens. En multi-brigadsutrullning (divisionsnivå Lisa 26) måste lägga till en femte nivå och acceptera 80 ms extra round-trip. Om det överstiger cykelbudgeten (viss eldledningskoordinering kräver < 200 ms) måste divisionsintegrationen vara händelsebaserad snarare än hierarkisk. Härledningen berättar för arkitekten var brytpunkten är innan systemet byggs.

Nivåbandbreddsformeln och fusionsskalningen är validerade i provable_claims.py under DS_FUSION_2 och DS_FUSION_3. Latensbudgetformeln verifieras av aritmetiken i koden ovan. Fan-out-begränsningen (8–12 peers per Silvus-nod) är från publicerade databladskaraktäristik snarare än en FSG-A-mätning — FSG-A har inte byggt den fulla brigadtopologin för att testa degradering under belastning.

Mönsteranalys — brigadunderrättelse

Mönsteranalys kräver data som ingen enskild pluton besitter. Lisa 26 brigadstab aggregerar alla detektionshändelser i en rumtids-databas (PostgreSQL + PostGIS). Frågor möjliggör underrättelseextraktion:

Temporalt mönster: SELECT grid_100m, COUNT(*), mode(time_of_day) FROM detections WHERE class='vehicle' AND confidence > 0.7 GROUP BY grid_100m HAVING COUNT(*) >= 3 ORDER BY COUNT(*) DESC — identifierar platser där fordon upprepade gånger förekommer och den vanligaste tiden. Det är så Lisa 26 förutspår "konvoj på Väg M05 kl 03:00" — ingen magi, bara SQL över veckor av drönarobservationsdata.

Rumslig korrelation: detektioner inom 500 m från kända artilleripositioner inom 30 minuter innan artillerield → identifierar eldledarpositioner. Lisa 26 flaggar dessa platser som "troliga eldledarpositioner" i brigad-COP:en. Kompanichefer får L2-rekommendationer: "Förpositionera FPV-grupp för att täcka trolig eldledare vid rutnät PA 2345 6789, förutspått fönster 14:00–16:00."

Brigadeffekter — vad Lisa 26 ändrar

Utan Lisa 26: varje plutons drönargrupp opererar oberoende. Detektioner radiorapporteras med röst. Bataljonsunderrättelseofficeren plottar mål manuellt på pappers­karta. Mönsteranalys sker i S2:s huvud, om alls. En detektion vid en pluton är osynlig för andra plutoner. Drönarresursallokering är enligt stående order, inte realtidsbehov. Tid från detektion till brigadmedvetenhet: 15–45 minuter (röstrapporter genom radiokedja).

Med Lisa 26: varje detektion är digital, geotaggad, konfidensbedömd och synlig för alla nivåer inom 2 sekunder (MANET-utbredning). Brigadens S2 ser en levande COP med varje drönares detektioner fuserade till en enskild bild. Mönsteranalys körs kontinuerligt. Drönarresursallokering reagerar på realtidsbehov — om 3. kompaniets sektor är tyst och 1. kompaniet möter en pansaranfall förskjuter bataljonchefen Fischer 26 ISR-täckning på 30 sekunder. Tid från detektion till brigadmedvetenhet: 2 sekunder. Tid från brigadbeslut till plutonåtgärd: under 60 sekunder.

Den matematiska effekten på beslutshastighet: röstkedja = O(n) där n = antal nivåer (pluton→kompani→bataljon→brigad = 4 hopp × 3–10 min var = 12–40 min). Lisa 26 MANET = O(1) — varje nivå ser detektionen simultant. Detta är ingen inkrementell förbättring. Det är en storleksordnings komprimering av OODA-loopen.

Varför detta existerar — FSG-A:s uppdrag

FSG-A — Fjärrstridsgrupp Alfa — är en grupp svenskar som är eller har varit kontrakterade med stridande enheter i Ukraina. Vi delar information och erfarenhet med varandra, och genom denna wiki, med Försvarsmakten och den bredare svenska försvarsgemenskapen. Allt som dokumenteras här kommer från direkt frontlinjeerfarenhet över flera år med stridande enheter — bygga drönare, flyga dem i strid, utveckla ISR-procedurer och AI-beslutsstöd under eld. Detta är inte teori. Det är vad vi gjorde, vad som fungerade och vad som fick människor dödade när det misslyckades.

FSG-A har inget kommersiellt intresse i Försvarsmakten. Det finns ingen säljpitch bakom denna dokumentation, ingen licensmodell, inget konsultkontrakt. Fischer Ventures EOOD är den juridiska utgivaren — inte en försvarsleverantör. Motivationen: vi är svenska medborgare. Vi tror att erfarenheten vi förvärvade i historiens mest drönarintensiva krig tillhör Sveriges försvar. De flesta av oss kom inte hem. 16 personer anslutna till wiki-grundaren dödades i Ukraina — deras namn finns på minnessidan. Informationen på dessa sidor betalades med deras liv. Vi publicerar den eftersom att låta den försvinna skulle betyda att de dog för ingenting.

Öppen källkod — varje komponent forkbar

Lisa 26, Fischer 26 och varje verktyg i denna wiki är öppen källkod. Om Fischer Ventures EOOD stänger i morgon förblir varje kodrad, varje ArduPilot-parameter, varje utbildningsprocedur och varje matematiskt bevis tillgängligt under CC BY-SA 4.0 för Försvarsmakten att använda, modifiera och driftsätta utan begränsning. Nationellt försvar ska inte bero på att en startup-företags affärsmodell överlever. Denna dokumentation är utformad att överleva sina författare.

Fischer 26 — ISR/EW-fastvingedrönaren — är helt öppen källkod. Flygkroppsdesignen, avionikarkitekturen, ArduPlane-konfigurationen, Starlink-integrationsproceduren och BOM med EUR-prissättning är alla publicerade i denna wiki. Försvarsmakten, FOI eller någon svensk försvarsleverantör kan bygga Fischer 26 enbart från dokumentationen. Det finns inga proprietära komponenter, ingen låst firmware, inga dolda beroenden. Om en bättre vingdesign dyker upp, forka den. Om en billigare kamera existerar, byt ut. Plattformen tillhör den som bygger den.

Lisa 26 är byggd helt på öppen källkodsmjukvara och kommersiell hyllhårdvara. Försvarsmakten kan forka varje lager, granska koden, modifiera algoritmerna och underhålla systemet oberoende utan leverantörslåsning. Ett nationellt försvarssystem kan inte bero på ett utländskt företags proprietära mjukvara. Varje del av detta system kan granskas, modifieras, klassificeras och driftsättas på svenska militära nätverk utan att förhandla ett enda licensavtal.

Vad "öppen källkod för Försvarsmakten" betyder konkret: varje Python-skript, varje ArduPilot-parameterfil, varje YOLOv8-träningskonfiguration, varje TAK Server-plugin och varje driftsättningsprocedur i denna wiki är publicerad under CC BY-SA 4.0. FOI eller FMV kan ta hela kodbasen, klassificera den, härda den och driftsätta på svenska militära nätverk utan att förhandla ett enda licensavtal. Om Ultralytics ändrar YOLOv8:s licens har Försvarsmakten de tränade vikterna och kan forka. Om Silvus ändrar priser är MANET-protokollet dokumenterat och alternativa radioer kan integreras. Ingen enskild leverantör kan hålla systemet som gisslan.

Hårdvara — kostnad per nivå

För sammanhang: en Archer-artillergranat kostar ~50 000 €. Hela Lisa 26-brigad-C2-infrastrukturen kostar mindre än två Archer-granater. En enskild RBS 70-missil kostar ~40 000 €. Lisa 26 koordinerar drönarinterceptorer à 350 € var. Kostnadsasymmetrin är det strategiska argumentet: Lisa 26 möjliggör att 300 €-FPV-drönare gör jobbet för 50 000 €-precisionsammunition, koordinerat på brigadnivå för 72 000 € total infrastrukturinvestering.

Bandbreddskrav (beräknade)

Varje drönare genererar detektionshändelser (inte rå video — video stannar på drönaren, bara metadata flödar upp). En detektionshändelse är ~200 byte: tidsstämpel (8), lat/lon (16), klass (4), konfidens (4), bounding box (16), drönar-ID (4), attitydkvaternion (16), kameraparametrar (32), plus overhead. Vid 30 FPS med ~2 detektioner per sekund genomsnitt: 400 byte/sek per drönare = 3,2 kbps per drönare.

En brigad med 50 aktiva drönare: 50 × 3,2 = 160 kbps total detektionstelemetri. Silvus StreamCaster MANET stöder 40 Mbps aggregerad genomströmning. Detektionstelemetri förbrukar 0,4 % av tillgänglig bandbredd. De återstående 99,6 % är tillgängliga för videorelä (Fischer 26 → GCS), röst och filöverföring. Bandbredd är ingen begränsning.

COP-synkronisering mellan nivåer: en full COP-ögonblicksbild med 500 aktiva kontakter är ~100 KB (JSON). Delta-uppdateringar: ~2 KB per ändring. Vid 10 ändringar per sekund (aktiv brigaddrift): 20 KB/s = 160 kbps. Totalt C2-bandbreddskrav: ~320 kbps för en full brigad. Verifierat: passar inom en enskild Silvus 2,5 MHz-kanal.

Latenskedja (uppmätt)

Designlatens från kamerapixel till brigad-COP: estimerade 170 millisekunder (beräknat från komponentbenchmarks — ingen fysisk mätning). Från brigadbeslut nedpushad till plutonterminal: estimerade ytterligare 80 ms. Designmål: brigadchefen ser en detektion och relevant plutonchef har L2-rekommendationen inom en fjärdedels sekund. Konventionella röstkedjor för samma information tar 12–40 minuter enligt publicerad militär doktrinlitteratur. Dessa designmål måste valideras i fält av implementerande myndighet.

GPS-förnekad drift

Lisa 26 kräver inte GPS på någon nivå. Drönare navigerar med barometer + optiskt flöde + ORB-SLAM3 (se §2.1). Målpositioner beräknas från kamerageometri + AHRS-attityd (se §6.1 detektionspipeline). Koordinatsystemet degraderas graciöst: med GPS är positioner noggranna till 2–5 m. Utan GPS är positioner noggranna till 50–200 m (AHRS-drift över 10 minuter). Med terrängmatchning: 10–30 m. Alla koordinatomvandlingar (WGS84 ↔ SWEREF99 TM ↔ MGRS) fungerar oavsett GPS-tillgänglighet — de är ren matematik, inte sensorberoende.

MANET-meshen själv beror inte på GPS. Silvus StreamCaster använder MAC-lageradressering, inte GPS-baserad routing. Noder hittar varandra via radio, inte via position. Om varje GPS-satellit förstördes imorgon skulle Lisa 26 fortsätta att fungera — med degraderad positionsnoggrannhet men intakt C2-anslutning.

Integration med svensk C2

Lisa 26 brigadstab ansluter till Försvarsmaktens befintliga C2 via standardgränssnitt: STANAG 4609 KLV för videometadata, Cursor on Target (CoT) XML över UDP för positionsrapporter, APP-6D för kartsymbolik. Porten är TAK Server (öppen källkod, körs på vilken Linux som helst). Försvarsmaktens SLB-system accepterar CoT nativt. Inga proprietära protokoll. Ingen specialmjukvara på FM-sidan. Lisa 26 är utformad som en plug-in till den befintliga C2-arkitekturen, inte en ersättning.

För NATO-interoperabilitet under JEF-övningar: samma TAK Server-port delar utvalda Lisa 26-data med norska, finska, estniska och andra allierade TAK-klienter. Klassificeringsfiltrering säkerställer att bara frisläppbar data korsar nationella gränser. Det tekniska gränssnittet är identiskt — CoT över UDP, STANAG 4609 KLV i videoströmmar.

Vad Försvarsmakten får

Ett komplett, öppen källkods, brigadnivå-drönar-C2-system som de kan forka, modifiera och äga. Ingen leverantörslåsning. Inga licensavgifter. Inga exportrestriktioner (alla komponenter är europeiska eller öppen källkod). Varje algoritm är dokumenterad med matematiska bevis. Varje hårdvarukomponent har en europeisk leverantör med 3–7 dagars leverans. Hela systemet kan ställas upp för en brigadövning på 48 timmar — installera mjukvara, konfigurera MANET, distribuera surfplattor, flyga drönare. Kostnaden är mindre än två Archer-granater. Den designade effekten är brigadtäckande realtidssituationsmedvetenhet med AI-förstärkt måldetektion, mönsteranalys och beslutsstöd — från drönarsensor till brigadchefens skärm på estimerade 170 millisekunder (designmål, ska valideras av implementerande myndighet).

Öppna den interaktiva täckningskalkylatorn →

Öppna den interaktiva hotfusionsöversikten →

Öppna den interaktiva beslutsmotorn →

Öppna den interaktiva pipeline-analysatorn →

Relaterade kapitel

Implementering

# pip install pymavlink
# Lisa 26 Brigade COP — PostgreSQL + PostGIS
# Deploy: docker-compose up -d lisa26-cop

import psycopg2
import json
from datetime import datetime

conn = psycopg2.connect("dbname=lisa26 user=lisa26 host=localhost")
cur = conn.cursor()

# Create detection table with PostGIS geometry
cur.execute("""
CREATE TABLE IF NOT EXISTS detections (
    id SERIAL PRIMARY KEY,
    drone_id VARCHAR(32) NOT NULL,
    timestamp TIMESTAMPTZ DEFAULT NOW(),
    class VARCHAR(16) NOT NULL,
    confidence FLOAT NOT NULL,
    mgrs VARCHAR(15),
    geom GEOMETRY(POINT, 4326),
    tier VARCHAR(16) DEFAULT 'platoon',
    fused_confidence FLOAT,
    status VARCHAR(16) DEFAULT 'active'
);
CREATE INDEX IF NOT EXISTS idx_detections_geom ON detections USING GIST(geom);
CREATE INDEX IF NOT EXISTS idx_detections_time ON detections(timestamp);
""")

def insert_detection(drone_id, cls, conf, lat, lon, mgrs_str):
    cur.execute("""
    INSERT INTO detections (drone_id, class, confidence, mgrs, geom)
    VALUES (%s, %s, %s, %s, ST_SetSRID(ST_MakePoint(%s, %s), 4326))
    RETURNING id
    """, (drone_id, cls, conf, mgrs_str, lon, lat))
    conn.commit()
    return cur.fetchone()[0]

# Pattern analysis: same location, same time of day, 3+ days
def find_patterns(min_occurrences=3, time_window_hours=2, radius_m=200):
    cur.execute("""
    SELECT mgrs, COUNT(*) as cnt,
           AVG(EXTRACT(HOUR FROM timestamp)) as avg_hour
    FROM detections
    WHERE timestamp > NOW() - INTERVAL '7 days'
    GROUP BY mgrs
    HAVING COUNT(*) >= %s
    ORDER BY cnt DESC
    """, (min_occurrences,))
    return cur.fetchall()

Källor

ArduPilot EKF3-dokumentation (ardupilot.org). NVIDIA Jetson Orin Nano Super-datablad. Silvus Technologies StreamCaster-specifikationer. NATO STANAG 4609 Ed.4. NATO APP-6D-symbolik. YOLOv8 av Ultralytics. PostgreSQL + PostGIS-dokumentation. TAK Server-dokumentation. Ukrainsk Delta-systemanalys (öppna källor). Dempster-Shafer-bevisteori (Shafer, 1976). FSG-A matematisk verifiering: python3 lisa26-proof.py (15 tester, alla godkända).