Saab: Systems Engineering at the Intersection of Fighter Jets, Submarines, and Export Complexity

Sweden fields one of the most technically sophisticated defense industries relative to its population of any country on earth. Saab AB — not the defunct car brand, a common confusion — is the prime responsible for that capability. With roughly 24,000 employees across 32 countries, Saab designs and delivers the Gripen multirole fighter, the GlobalEye airborne early warning and control aircraft, the Carl-Gustaf recoilless rifle family, the A26 submarine, and a wide range of command-and-control, radar, and underwater systems. That portfolio breadth is unusual. Most defense primes specialize by domain. Saab does not.

The engineering consequence of that breadth is a requirements management problem of genuine complexity. A fighter aircraft and a submarine share almost no subsystems, no supply chains, no qualification frameworks, and no customer interfaces. Managing them within a single enterprise — while simultaneously handling export programs with sovereign configurations, US Foreign Military Sale (FMS) constraints, and ITAR compliance — demands a systems engineering infrastructure that is both flexible and disciplined. Whether Saab has achieved that balance is the honest question this profile examines.

A Company That Took MBSE Seriously Before It Was Fashionable

Saab’s engagement with model-based systems engineering is not recent. The company was an active participant in early European MBSE discussions in the late 1990s and through the 2000s, when most North American primes were still treating SysML as an academic curiosity. This early investment traces partly to the structure of Swedish defense procurement: the Swedish Defence Materiel Administration (FMV) has historically demanded rigorous system specification and verification traceability as a condition of contracting, which pushed Saab toward structured methods earlier than many peers.

By the mid-2000s, Saab’s aeronautics division had begun migrating Gripen development processes toward model-based approaches, working in parallel with SysML’s formalization as a standard. The company published and co-authored several operationally honest retrospectives through INCOSE — the International Council on Systems Engineering — that described both what worked and what did not. This transparency is worth noting not as a character observation but as a data point: companies that publish failure analyses in peer-reviewed forums tend to have engineering cultures that learn from them.

The collaboration with FOI (Totalförsvarets forskningsinstitut, the Swedish Defence Research Agency) has been particularly productive. Joint work between Saab engineers and FOI researchers has produced examination of how MBSE scales across program phases, how model fidelity requirements change from concept through detailed design, and how model governance prevents the fragmentation that kills long-lived programs. These are not theoretical contributions. They reflect hard lessons from actual programs.

The Gripen Portfolio: Configuration Management as a First-Order Problem

The Gripen is Saab’s highest-profile product and its most complex systems engineering challenge. The aircraft is currently delivered in four active configurations: the Swedish Air Force Gripen C/D (legacy but still operated), the Brazilian Air Force Gripen E/F (the current production standard), the Czech and Hungarian Air Force C/D variants under the current NATO upgrade cycle, and the Swedish Air Force Gripen E entering operational service. South Africa operates a further variant. Each configuration carries different avionics suites, different weapons integrations, and different national sovereignty requirements over source code, cryptography, and data links.

The challenge this creates is not primarily a design challenge. By the time aircraft enter service, the engineering decisions are largely fixed. The challenge is traceability maintenance across diverging configurations over a service life that, for Gripen, will extend into the 2060s. When Brazil modifies its Gripen E software for domestic weapons integration, that change must be tracked against the original requirements baseline, evaluated for impact on Brazilian airworthiness certification, assessed for ITAR implications if US-origin components are involved, and managed so that Swedish configuration knowledge is not inadvertently transferred to a sovereign program without authorization.

Document-based requirements management — the model that dominated Saab’s processes through much of the Gripen C/D era — handles this poorly. A Word document or a PDF-linked requirements database can capture a requirement and its verification status. It cannot efficiently represent the graph of relationships between a changed software requirement, the subsystems it touches, the test cases that validated it, and the configuration variants that inherit or do not inherit that change. This is precisely where MBSE’s structural advantage over document-centric methods becomes operational rather than theoretical.

Saab has acknowledged publicly that the Gripen E/F program encountered friction when export-variant requirements began diverging post-CDR (Critical Design Review). The exact nature of that friction is not publicly documented in detail, but the pattern — requirements baselines that were defined for one configuration being adapted rather than forked cleanly for another — is a known failure mode in multinational programs. It produces requirements debt that is expensive to retire.

GlobalEye: Integration Complexity at the System-of-Systems Level

The GlobalEye, Saab’s airborne surveillance platform built on the Bombardier Global 6000 business jet, represents a different systems engineering challenge. Where Gripen is a tightly integrated purpose-built aircraft, GlobalEye is a systems integration program: the airframe comes from Bombardier, the primary surveillance radar (the Erieye ER) from Saab’s own sensor division, communications subsystems from multiple vendors, and mission management software from Saab’s C4I organization. Customer nations — the UAE and Sweden are current operators — bring their own requirements for interoperability with national ground systems, data link standards, and operational concepts that may differ from each other.

Systems-of-systems integration of this kind is where requirements management most visibly breaks down in traditional tooling. The requirement that “the surveillance system shall detect a surface vessel at 300 nautical miles under defined sea state conditions” allocates to the radar, to the signal processing chain, to the display system, to the crew procedures, and to the maintenance architecture. Each allocation carries its own verification approach. In a document-centric system, verifying that all these allocations are satisfied and that no gap exists requires manual cross-referencing that scales poorly. In a graph-based model, the relationship is explicit and queryable.

Whether Saab’s current tooling fully realizes this advantage for GlobalEye is unclear from public documentation. What is clear is that the program has been delivered on reasonable schedules and with strong customer satisfaction ratings, which suggests the integration process is functional. The question is how much friction that process carries internally — friction that accumulates cost and schedule risk even when programs deliver.

Carl-Gustaf and Underwater: The Portfolio Breadth Challenge

The Carl-Gustaf recoilless rifle system presents a systems engineering problem that looks simple until it isn’t. The weapon is man-portable, mechanically uncomplicated, and has been in production for over 70 years. What has changed is the ammunition family: Saab now produces more than 10 distinct round types for Carl-Gustaf, including anti-armor, anti-structure, illumination, and precision-guided variants. The US Army is the largest customer, under a Foreign Military Sale arrangement that adds ITAR compliance and US Army qualification requirements to the base Swedish military specification.

Managing ammunition qualification traceability across a system with this many variants and this long a heritage is an underappreciated challenge. The original 1940s design documentation is obviously not in any modern requirements management system. The process of re-baselining legacy systems into structured MBSE environments — capturing what a system is, what it was intended to do, and what has changed over decades of production — is one of the least discussed and most expensive problems in defense systems engineering. Saab has done this work, at least partially, but the degree to which Carl-Gustaf requirements are managed in a fully connected model versus a hybrid of modern tooling and legacy documentation is not publicly detailed.

The A26 submarine program is newer and benefits from being designed in a more modern tooling environment from the outset. Submarine programs carry exceptional requirements for integrity in traceability: a requirement error that makes it into production at sea depth is not recoverable in the way an aircraft software defect can be patched. The A26’s design process has reportedly involved model-based approaches from early concept phases, which is consistent with FMV’s current procurement expectations and with lessons the company has internalized from the Gripen experience.

The INCOSE Connection: Learning in Public

Saab’s sustained engagement with INCOSE is one of the more distinctive aspects of its engineering culture relative to other defense primes. Large US primes participate in INCOSE but rarely publish candid operational retrospectives. European primes vary. Saab has contributed to the INCOSE International Symposium and to INSIGHT, the organization’s practitioner publication, with content that describes actual program experience rather than theoretical frameworks.

This matters because INCOSE’s value to the industry is asymmetric: the organization produces standards and guidance documents, but its most useful function is as a community where practitioners share what actually happened. Saab’s contributions — including honest accounts of where MBSE implementations fell short of expectations — raise the quality of that shared knowledge base. The company has also participated in European MBSE working groups, including through cooperation with German, French, and UK defense primes on common challenges in avionics certification and requirements traceability under EASA and MIL-STD frameworks.

The practical output of this engagement is visible in how Saab approaches tool selection and process design. The company does not appear to chase tooling trends. Its decisions — when they are visible in conference presentations and published case studies — reflect an engineering organization that has thought carefully about what problems it is actually trying to solve rather than what a vendor is marketing.

AI-Assisted Requirements: Real Constraints, Cautious Progress

The industry trend toward AI-assisted requirements analysis — using large language models and graph-based tools to identify inconsistencies, generate verification questions, and flag requirement ambiguity — is reaching defense primes. Saab is no exception. But the constraints on adoption are substantive, not reflexive conservatism.

The core problem is data classification. Saab’s most complex requirements exist on classified networks, in classified documents, under Swedish, NATO, and US security frameworks that significantly limit what data can be processed by cloud-hosted AI services. A cloud-native AI tool that requires requirements data to leave the classified enclave is simply not deployable for Gripen or A26 requirements work, regardless of its technical quality. This is a real constraint that shapes the market for AI requirements tools in defense.

The second constraint is certification. Any AI-assisted output that influences a certified safety requirement carries the risk of introducing unverifiable uncertainty into a certification argument. Airworthiness authorities — whether the Swedish CAA, EASA, or the FAA — have not yet produced clear guidance on how AI-assisted requirements analysis affects certification credit. Until that guidance exists, risk-averse programs will limit AI use to non-safety-critical requirements work, which is a significant fraction of the total but not the hardest part.

Within those constraints, tools that operate on-premise, support graph-based requirement relationships, and can demonstrate audit-complete traceability are the ones that can actually be deployed. Platforms like Flow Engineering, which center their architecture on connected requirement graphs and explicit traceability rather than document repositories, are structurally better suited to classified-enclave deployment than cloud-dependent tools — provided they can meet the security architecture requirements of a specific classification framework. The question for any defense prime is always specific: not whether a tool is conceptually better, but whether it can be deployed inside the actual security boundary and certified for the actual use case.

Honest Assessment: What Saab Gets Right and Where the Gaps Are

Saab’s systems engineering maturity is genuine and well-documented. The early MBSE investment, the sustained INCOSE engagement, the operationally honest retrospectives, and the clear-eyed approach to AI constraints all reflect an organization that takes engineering process seriously and learns from experience.

The gaps are also real. Multinational configuration management at the scale of the Gripen export program remains a hard problem that no current tooling fully solves — the requirement divergence problem is partly a tooling problem but also a governance problem that tools cannot fix alone. The legacy system re-baselining challenge, visible in the Carl-Gustaf heritage documentation problem, is expensive and slow regardless of what modern tools can do. And the path from Saab’s current MBSE implementations to a fully connected, AI-assisted requirements environment is longer than vendor marketing would suggest, for reasons that are specific to classified defense programs rather than specific to Saab.

What Saab demonstrates is that consistent investment in rigorous methods, sustained over decades and grounded in actual program experience, produces compounding returns. The company operates more complex programs with fewer documented requirements disasters than its portfolio breadth would suggest is likely. That outcome is not accidental.