LEARN // PRESENTATIONS
Role Presentations — F-35 MPE
Three role-framed decks that walk through the Mission Planning Environment from an Executive, System/Software Architect, and MBSE Architect view. Educational use only — based on public, unclassified information.
◤ ◤ DECKS
Pick your perspective
System / Software Engineering Architect
F-35 MPE — From Capability to Code
How a System/Software Architect reads the mission, decomposes capability into L0–L4 requirements, and lands them in MPE software components and interfaces.
◆ ~45 min · 10 slides◆ SE/SW architects, lead engineers, integration & test leads
MBSE Architect
F-35 MPE — Modeling the Mission, Not Just the Docs
How an MBSE architect frames the F-35 MPE using SysML and DoDAF views, keeping the model as the source of truth for capability, behavior, and verification.
◆ ~45 min · 10 slides◆ MBSE architects, model stewards, V&V leads, chief engineers
Executives
F-35 MPE — Strategy, Risk, and Program Health
A leadership-level view of the Mission Planning Environment: strategic value, capability outcomes, risk posture, governance, and the metrics that inform executive decisions.
◆ ~30 min · 10 slides◆ Program executives, PMs, PEOs, portfolio managers, board advisors
◤ ◤ DECK · SYSTEM / SOFTWARE ENGINEERING ARCHITECT
F-35 MPE — From Capability to Code
How a System/Software Architect reads the mission, decomposes capability into L0–L4 requirements, and lands them in MPE software components and interfaces.
~45 min · 10 slides · SE/SW architects, lead engineers, integration & test leads
- Slide 01
Mission Context — What MPE Does for the F-35
- Mission Planning Environment (MPE): pre-mission route, threat, weapon, comm, and DTC (Data Transfer Cartridge) generation.
- Outputs feed the jet's mission data load — directly affecting sensor fusion, EW, and weapon employment.
- Architect's job: keep the chain operational need → capability → system function → software unit traceable.
- Slide 02
Capability Decomposition (L0 → L4)
- L0 operational need → L1 system capability → L2 subsystem requirements → L3 component → L4 software unit.
- Each level adds verifiability: L1 = demonstrate, L2 = test, L3 = unit test, L4 = code review + static analysis.
- Architect owns the rationale at every hand-off, not just the text.
- Slide 03
MPE Logical Architecture
- Core blocks: Mission Data Manager, Route Planner, Threat Engine, Weapons Pairing, Comms Plan, DTC Builder.
- External interfaces: intel feeds, terrain/elevation DBs, weapons effectiveness data, time/PNT services.
- Architect defines the seams (interfaces) before the implementations.
- Slide 04
Interface Control — ICDs & Data Item Dictionary
- Every cross-component message must be in an ICD with versioning and backward-compat policy.
- Use the Data Item Dictionary as the single source of truth for units, ranges, and encodings.
- Architect signs off on breaking changes — never the implementing team alone.
- Slide 05
Non-Functional Requirements that Bite
- Determinism of plan generation, classification handling (cross-domain), DTC load time, and update cadence.
- Cyber: integrity of mission data from MPE through DTC into the jet.
- Architect makes these visible at L1/L2 — not buried in code comments.
- Slide 06
Software Allocation & Build Strategy
- Allocate L3/L4 reqs to modules; choose language/runtime per safety & certification class.
- Define static analysis, MISRA/secure-coding gates, and dependency policy up front.
- Plan for partial rebuilds — MPE deltas ship more often than airborne OFP.
- Slide 07
Verification Strategy (V-Model in Practice)
- Left side: requirements at each level. Right side: matching test artifact.
- Unit → integration → system → operational acceptance, each tied to L4 → L1.
- Architect ensures every requirement has exactly one owning test.
- Slide 08
Change Control & Regression
- Threat library update? New weapon? Comms plan format change? Each triggers a scoped regression run.
- Maintain a 'blast radius' map: requirement → modules → tests → mission scenarios.
- Architect approves the regression scope, not just the code diff.
- Slide 09
Common Failure Modes
- Skipping L2: L1 capabilities wired directly into L4 code — untestable and unmaintainable.
- ICDs treated as documentation, not contracts — silent drift between MPE and aircraft.
- Performance & cyber NFRs discovered at IV&V instead of design.
- Slide 10
Architect's Checklist
- Every L1 traces to an operational need and at least one verification activity.
- Every external interface has an ICD, an owner, and a versioning rule.
- Every NFR is measurable and assigned to a component.
- Every change has a defined regression scope before merge.
◤ ◤ DECK · MBSE ARCHITECT
F-35 MPE — Modeling the Mission, Not Just the Docs
How an MBSE architect frames the F-35 MPE using SysML and DoDAF views, keeping the model as the source of truth for capability, behavior, and verification.
~45 min · 10 slides · MBSE architects, model stewards, V&V leads, chief engineers
- Slide 01
Why Model the MPE
- MPE sits between operators, intel, and the jet — too many interfaces for documents alone.
- A model gives one place where capability, behavior, structure, and verification co-exist.
- MBSE architect owns the model's integrity, not the slideware around it.
- Slide 02
Operational Frame (DoDAF OV/CV)
- CV-1 sets the vision; CV-2 the capability taxonomy (Plan, Brief, Load, Debrief).
- OV-1 high-level operational concept ties pilot, planner, and intel together.
- Anchor every downstream artifact to these — otherwise traceability collapses.
- Slide 03
Use Cases & Actors
- Primary actors: Mission Planner, Intel Analyst, Pilot, Maintainer.
- Use cases: Build Mission, Update Threat Picture, Generate DTC, Debrief Mission.
- SysML use-case diagram is the bridge from CV/OV into SV/system behavior.
- Slide 04
Structure (BDD/IBD) and Resource Flows (SV-2)
- BDD: MPE blocks (Planner, Threat Engine, DTC Builder, etc.) and their ports.
- IBD: how blocks connect at run-time — flows of mission data, intel, time.
- SV-2 mirrors this at the system-of-systems level.
- Slide 05
Behavior (Activity / State / Sequence)
- SV-4 captures system functions; activity diagrams realize them.
- State machines for DTC lifecycle (Draft → Validated → Signed → Loaded → Consumed).
- Sequence diagrams for cross-component negotiations (e.g., threat update mid-plan).
- Slide 06
Requirements in the Model (L0–L4)
- Requirement elements «satisfy» blocks and «verify» test cases.
- L0/L1 link to capabilities (CV-2); L2–L4 link to blocks and allocations.
- SV-5 traceability matrix is generated from the model, not hand-written.
- Slide 07
Measures: MOE / MOP / KPP
- MOEs sit on capabilities; MOPs on system functions; KPPs are contractually binding.
- Each measure has a parameter, target, and verification method modeled, not just stated.
- If an MOE has no MOP underneath it, it cannot be argued at IV&V.
- Slide 08
Verification & IV&V Hooks
- Every «verify» relationship points at a test case with a method (Test/Demo/Analysis/Inspect).
- IV&V consumes the model — don't ship a separate compliance doc that drifts.
- Coverage gaps surface as a model query, not a spreadsheet audit.
- Slide 09
Risk in the Model
- Risk register elements link to capabilities, requirements, or blocks they threaten.
- Mitigations link to design changes or new verification activities.
- A risk with no model linkage is a risk no one will act on.
- Slide 10
MBSE Architect's Checklist
- Every capability has at least one use case, one block allocation, and one MOE.
- Every requirement has «satisfy» and «verify» links — no orphans.
- Every interface has a port, a flow, and an ICD reference.
- The model — not the document — is the artifact reviewed at gates.
◤ ◤ DECK · EXECUTIVES
F-35 MPE — Strategy, Risk, and Program Health
A leadership-level view of the Mission Planning Environment: strategic value, capability outcomes, risk posture, governance, and the metrics that inform executive decisions.
~30 min · 10 slides · Program executives, PMs, PEOs, portfolio managers, board advisors
- Slide 01
Strategic Context — Why MPE Matters
- MPE is the bridge between mission tasking and combat readiness: every route, threat, weapon, and comm plan starts here.
- A failure in planning cascades to sensor fusion, electronic warfare, and weapons employment in the jet.
- Executive priority: keep planning throughput high, classification handling clean, and update cadence aligned with operational tempo.
- Slide 02
Capabilities Map — What the Program Delivers
- Plan: multi-aircraft route, threat, and weapons pairing within tasking window.
- Brief: pilot-readable mission products aligned with current intel.
- Load: validated Data Transfer Cartridge (DTC) delivered to the flight line.
- Debrief: mission data back-flow for intelligence and readiness analytics.
- Slide 03
Measures of Success — MOEs, MOPs, and KPPs
- MOEs sit on operational outcomes (e.g., mission-ready rate). MOPs sit on system functions (e.g., plan generation latency).
- Key Performance Parameters (KPPs) are contractually binding — failure means a breach or waiver.
- Executives should review the KPP-to-budget trace monthly; an MOE without an MOP underneath it is unarguable at review.
- Slide 04
Program Health — Leading Indicators
- Requirements volatility: churn rate at L1/L2 signals architecture instability.
- Integration readiness: percentage of ICDs baselined, tested, and closed against plan.
- Defect escape rate and mean-time-to-remediate by severity class.
- TFC closure velocity vs. committed release content — the pulse of deliverable output.
- Slide 05
Risk Framework — From Technical to Strategic
- Technical risks: interface drift, threat library staleness, classification cross-domain handling.
- Program risks: subcontractor health, clearance pipeline bottlenecks, certification schedule slippage.
- Strategic risks: adversary countermeasures outpacing intel refresh, platform obsolescence.
- Every risk in the register links to a capability, a requirement, or a schedule milestone.
- Slide 06
Governance & Change Control
- The SCCB is the single forum that approves baseline changes — requirements, architecture, interfaces, and schedule.
- Executive role: ensure impact analysis includes cost, risk, and verification before a change is approved.
- Uncontrolled drift at L1/L2 is the leading cause of integration overrun and test re-baseline.
- Slide 07
Compliance, Certification, and Audit Readiness
- The V-Model produces paired evidence: every specification level has a matching verification level.
- IV&V consumes the model directly — a separate compliance document that drifts is an audit liability.
- Cyber integrity of mission data from MPE through DTC into the jet is a certification gate.
- Slide 08
Technology Roadmap & Modernization
- Current baseline: desktop-heavy planner moving toward distributed, containerized services.
- Cloud-adjacent intel feeds, AI-assisted threat pairing, and automated DTC validation are on the horizon.
- Modernization must not outpace certification — every new runtime or algorithm needs a safety and security case.
- Slide 09
Vendor & Supply Chain Resilience
- Map critical-path dependencies: terrain databases, threat libraries, time/PNT services, and hardware interfaces.
- Single-source components require a continuity plan; open-standard interfaces reduce lock-in.
- Executive oversight: review vendor financial health, export-control exposure, and clearance capacity quarterly.
- Slide 10
Executive Decision Checklist
- Every capability gap has an L0 need, an allocated budget, and a target closure date.
- Every KPP has a monthly trend line and an owner with escalation authority.
- Every major change has an SCCB-approved impact analysis covering cost, risk, and verification.
- The model — not a slide deck — is the artifact reviewed at program milestones.