Elements of Evidence Between validating a known mis - sion gap and commencing design of a new materiel solution, equipping commands often build mission mod - els using mission engineering. WSE 032 begins with mission threads ex - pressed through use cases, activ - ity flows, and state-based execut - able simulations. Students define operational scenarios, decompose them into functions, and represent system behavior through state ma - chines. These models lay a founda - tion for mission need specificity that can be decomposed into functions, which are further decomposed into components and system behavior. Figure 1 shows an actor activity se - quence model built by students dur - ing WSE 032. State machine modeling cap - tures the subsystem’s response and information-exchange logic and tim - ing under different environmental conditions. The calibration exposes
infrared sensors, and remote-control systems are used in the workshop. The focus is on concept explora - tion, evaluation of alternative de - signs, rapid prototyping and testing, and source selection considerations. Participants are required to track planned and executed cost, sched - ule, and performance updates within a single, cloud-accessible database. The combined instructional hours provide a robust experiential learning opportunity and demonstrate that all activities, from capability mission modeling to system sustainment, can be managed within the Cameo/ Temporary Works Coordinator (TWC) framework. While this framework is not the only IT software stack avail - able for integrated design environ - ments, it is a satisfactory option. Furthermore, creative integration suggests that specialized modeling need not be limited to modern appli - cation program interfaces.
interaction points that are insightful for early risk identification and miti - gation planning as well as test plan - ning, as demonstrated in Figure 2. Requirement-to-function mapping is well supported. Requirements link to functions, functions link to archi - tecture, and architecture links to test validation planning as shown in Fig - ure 3. The result is a mission-driven architecture tied to operational use rather than vendor-locked design. The second workshop, WSE 006, extends this product development life-cycle methods pathway beyond the basis subsystem expression into later-stage engineering and technical management activities. The common framework easily stores schedule, risk, cost, and performance test data in a single, cloud-distributed, authori - tative source of truth accessible to all cleared functional representatives on the IPT. It is reasonable to consider sched - uling sophistication that may require a very advanced integrated master schedule. However, wavetop mile - stones and dependencies can be built into TWC as a Gantt Chart within the model and tied to system ele - ments, production milestones, and test events (Figure 4). Risk elements and risk levels are stored as struc - tured data linked to the associated system components. According to the DoW’s Fiscal Year 2025 budget justification, unit materiel costs and related produc - tion data can be clearly documented and accessed within digital acquisi - tion models. The use of distributed and authoritative structures in these models aims to bring together infor - mation previously managed sepa - rately. In a classical policy-driven, document-based environment, cost, schedule, and risk reside in separate digital objects—often across different servers and access points. Here, they exist as views of one model. A change in design or material costs cascades to updates in schedule dependen - cies, cost estimates, and risk expo - sure without manual change manage -
Figure 1. Mission Engineering Use Case—Actor Activity Sequence Model from WSE 032
<allocate> Starship Captain
<allocate> Starship Weapons Operator
<allocate> Photon Torpedo
coordinates : Enemy Position
Upload Tracking Information
Ship Detected
Track Enemy Position
fire torpedo
M 2
M 1
Track Enemy Position
Monitor Behavior
Load Torpedo
[lost track]
[track successful]
[else]
DP 1
Update Enemy Position
DP 2 [destroyed in flight]
[acting aggressively]
coordinates : Enemy Position
[else]
Self Destruct
Destroyed
Hit Target
fire torpedo
intruder detected
torpedo detonated
M 3
DP 3
torpedo detonated
Source. Author
22 DEFENSE ACQUISITION MAGAZINE | SEPTEMBER –OCTOBER 2026
Made with FlippingBook - Online Brochure Maker