How Jama, Cameo, MATLAB, Simulink and AFSIM Fit Together, and Where the Glue Is a Technology Preview

Somebody will draw you five boxes. Requirements live in Jama Connect. Architecture lives in Cameo. Algorithms live in MATLAB. Dynamics live in Simulink. The whole thing gets flown against a threat in AFSIM. Then they draw arrows between the boxes and call it a digital thread.

The boxes are mostly right. The arrows are where the story is, and the arrows are the part almost nobody checks. So I went and checked them, against the vendors' own documentation rather than their own marketing, and the gap between those two things is large enough to plan a program around.

Start with the names, because three of the five are wrong on most diagrams

Cameo Systems Modeler is not a current product name. Dassault Systèmes, which acquired No Magic in 2018, says on its own page that the tool is "Formerly known as Cameo Systems Modeler, now rebranded as CATIA Magic Cyber Systems Engineer". The old name refuses to die anyway: the documentation still lives at docs.nomagic.com, and the plugins are still Cameo DataHub and Cameo Simulation Toolkit. Both names are load-bearing.

Simulink Requirements is also gone, renamed Requirements Toolbox in R2022a. That rename was substantive rather than cosmetic: it dropped the Simulink dependency, so requirements can link to plain MATLAB code, which is why it belongs at the algorithm altitude and not only the block-diagram one.

And AFSIM does not stand for Air Force Simulation. The AFRL-authored overview at CSIAC is blunt that "the AF in the AFSIM name does not stand for Air Force". It is the Advanced Framework for Simulation, Integration and Modeling, and it did not start life in the government: Boeing put roughly 35 million dollars of its own research money into it between 2003 and 2013, then transferred it to AFRL with unlimited rights.

The altitude ladder is roughly right, and it is not a treaty

The intuition behind the five boxes is that each tool owns a band of abstraction. It mostly holds. But two things complicate it, and both matter if you are planning work.

The first is that AFSIM does not cede the engineering band. The CSIAC overview says AFSIM "spans a broad spectrum of military simulations, to include the engineering, engagement, mission, and 'campaign-lite' level via analytic wargaming and experimentation." Its engagement level is "a brief exchange between two entities, or platforms," its mission level "a series of combat exchanges between multiple Red and Blue aircraft over the duration of a single sortie or mission, nominally a few hours." What the source says is narrower than a boundary: AFSIM's development focus "has been primarily at the engagement and mission level," and "other M&S tools are leveraged when needing to more fully explore engineering or full campaign modeling, such as the Synthetic Theater Operations Research Model (STORM)." That is emphasis, and reaching for a better tool, not a fence. AFSIM's modular design deliberately "allows the modeler, rather than the AFSIM programmer, to determine the appropriate level of fidelity," which is the opposite of a fixed altitude.

The second complication is that the vendors are climbing toward each other. MathWorks sells System Composer, its own MBSE architecture tool, which imports SysML and AUTOSAR, allocates requirements, and hands off to Simulink. That is Cameo's altitude, sold by the company that owns the two altitudes below it. These five tools are not a negotiated division of labour. They are five vendors each trying to be more of the diagram.

The Jama to Cameo link: read both documents

This is the part worth the price of admission. Jama Software's datasheet for Cameo DataHub, dated September 2024, describes the connector as a plugin "developed by Dassault Systèmes" that "provides engineers with a seamless view between CATIA Magic and Jama Connect by synchronizing any model elements, diagrams, or traces" and "ensures data, relationship, and process consistency across each tool by eliminating the error-prone manual integration process."

Now read Dassault's own documentation for that same connector. The Cameo DataHub 2024x page for the Jama Connect data source says the driver "is only available as a technology preview and should not be used for production." It says "currently, you can only synchronize the selected part of your project from Jama Connect to the Cameo Model." It publishes its known limitations in plain sight: "the link representation in the Cameo Datahub tree is incorrect," "the sync icon is not shown for child elements," "the project structure is not copied correctly to the modeling tool." For an on-premise Jama server you have to add the certificate first, "otherwise it may cause your modeling tool to crash." Two-way synchronization is listed under features "expected in next releases."

It did not fully graduate. In Cameo DataHub 2024x Refresh2 the page title drops "Technology preview" and the production warning is gone, but the version news still states that synchronization "is currently only supported from JAMA Connect to the model." As of the newest publicly documented release, the first-party link between the requirements tool and the architecture tool runs in one direction. Notice also that the two documents disagree about which way diagrams travel: the datasheet says a diagram synced from CATIA Magic becomes an image in a Jama description field, while the Refresh2 notes say diagrams sync from Jama Connect into the model's Text property. I am not going to resolve that by picking one. Both were published by the parties involved, and they do not match.

There is a way around it, and the way around it is telling. Jama's own blog documents reaching Cameo using Intercax Syndeia, a third-party commercial platform that federates models across SysML tools, PLM, CAD, requirements tools, JIRA, GitHub and MATLAB/Simulink. Jama documents an OSLC route as well. So there are at least three distinct paths from Jama to Cameo: one first-party and one-way, one somebody else's product you have to buy, and one a protocol. That is not a thread. That is a decision.

The Cameo to Simulink link is not co-simulation, and the docs say so

Cameo Simulation Toolkit has a feature literally named "Simulink co-simulation." It is not co-simulation. Dassault's own documentation says "simulation executes the entire Simulink model (*.slx) on all steps, if there are any value changes in the input," describes the behaviour as atomic calculations, and adds that "it occurs as one step of Simulation time, the same as FMU." That is model invocation. Coupled solvers exchanging state at a communication interval, which is what co-simulation means in the FMI sense, is not what is happening. You drag a .slx into a diagram, the block gets a SimulinkBlock stereotype, and you wire ports by name. Models without input or output ports are not executed at all.

The MATLAB link underneath it is real but narrow. Cameo uses MATLAB as an external Evaluator for opaque expressions written in MATLAB syntax. It needs MATLAB R2016b or later, installed locally, 64-bit to match the tool, registered by home directory, with a restart. The Java coupling is explicit: "MATLAB 2023b requires JDK8 and 2024a (or later versions) work with JDK8, 11 and 17." This is a local Java bridge to an installed copy of MATLAB, not a service and not a model exchange.

The vendor-neutral standard has a license-gated on-ramp

FMI is the honest answer to tool coupling: a free standard, maintained as a Modelica Association Project, that packages a dynamic model as a ZIP of XML, binaries and C code called an FMU. Current release is 3.0.2, and roughly 280 tools support FMI across all versions. FMI 3.0 defines three interface types, and the distinction is exactly the one Cameo's feature name blurs: Model Exchange hands an ODE to the importer's solver, Co-Simulation ships its own solver inside the FMU, and Scheduled Execution lets an external scheduler fire model partitions.

Importing an FMU into Simulink is native, through the FMU block, covering FMI 1.0, 2.0 and 3.0. Exporting one is not free. MathWorks now lists Simulink FMU Builder as a separate product, not included with Simulink, and generating FMUs with C source code requires Simulink Coder or Embedded Coder on top. The predecessor route survives as a support package on File Exchange, but it requires MATLAB Compiler and Simulink Compiler. Either way, the exit door to the vendor-neutral standard costs at least two more licenses.

The AFSIM link is the one nobody can show you

Here the public record simply stops. No first-party, documented FMI bridge between AFSIM and MATLAB or Simulink appears in any open source I could find. What the record does describe is that AFSIM's architecture "empowers developers to write custom plug-ins or adaptors in modern C++," and that AFSIM output "formats are highly structured and support postprocessing through tools written in Python, MATLAB, or R." Post-processing plus bespoke C++ is the "you will write a script" category.

And this one is structurally unfalsifiable from outside, which is its own fact. DSIAC states that "all components of AFSIM are export controlled. All output from AFSIM is also export controlled, regardless of input." Core software carries Distribution Statement F, documentation carries Distribution Statement C, and access requires an Information Transfer Agreement or MOU with AFRL. AFSIM literature calls itself government-owned and open-sourced. That does not mean open source in the sense you are thinking. It means the source is furnished to people permitted to have it. Without a government or cleared-contractor relationship you cannot obtain AFSIM, and you cannot read the documentation that would tell you whether the arrow on the diagram exists.

The vocabulary is worse than the tooling

Here is the tell that reorganizes everything. The 2018 DoD Digital Engineering Strategy, published in June 2018 with a foreword signed by Michael D. Griffin, is universally credited with launching "digital twin" and "digital thread" in defense. It contains the phrase "digital twin" exactly zero times. "Digital thread" appears once, inside an A-10 sustainment case study, never as a definition. "Authoritative source of truth" appears 53 times. MBSE, SysML, MATLAB, Simulink and V-model each appear zero times. The document's center of gravity is Goal 2, "Provide an Enduring, Authoritative Source of Truth," defined functionally rather than by tool, and the strategy says outright that it describes the "what" while implementers must develop the "how."

The DoD twin definition arrives five years later, in DoD Instruction 5000.97, published December 21, 2023. Per the OUSD SE&A summary sheet, a digital twin is "a virtual representation of a product, system, or process that uses data to mirror and predict system activities and performance of its physical twin." Set that against what the term meant when NASA and the Air Force Office of Scientific Research coined it in 2012: "an integrated multiphysics, multiscale, probabilistic simulation of an as-built vehicle or system," fused with sensor updates and fleet history, and "ultra-realistic." The bar fell that far in eleven years, inside the same government.

Nobody agrees on the word. The Digital Twin Consortium, a program of the same OMG that owns SysML, requires synchronization "at a specified frequency and fidelity." GAO's own footnote definition demands the model update in real time, stricter than the instruction's. The taxonomy that actually settles arguments is Kritzinger and colleagues (2018), which classifies by data integration: a digital model has manual flow both ways, a digital shadow has automatic one-way flow from physical to digital, and only a digital twin has automatic bidirectional flow. They reported that literature on the true twin was scarce next to the lower two stages. The defense test community adopted that taxonomy in 2024 to normalize "the definition of digital twin within the Test and Evaluation (T&E) community," which is an admission from inside the house. And a 2025 study running NLP over more than 15,000 publications found that "terminological consensus remains out of reach", reporting that even bidirectional data flow was "not yet fully mature" in the digital twins of the built environment it studied.

So does the toolchain work?

The honest answer is that almost nobody has measured. Henderson and Salado (2021), publishing in INCOSE's own journal, reviewed the literature and found that "two thirds of claimed MBSE benefits are only supported by perceived evidence, while only two papers reported measured evidence," concluding that the evidence "remains inconclusive." That is an evidentiary vacuum, not a negative verdict, and it would be the same sin in reverse to read it as proof MBSE fails.

The integration problem is not new information either. INCOSE named it in Systems Engineering Vision 2020, published in September 2007, listing as MBSE inhibitors the "inherent difficulty integrating models across organizational, lifecycle and other boundaries" and the "limitation of model /data exchange capabilities within the modeling tools." Nineteen years later, the first-party Jama connector syncs one way.

Then there is GAO-26-107009, from December 2025. GAO found that none of the acquisition strategies and test plans for the three Air Force programs it reviewed "considered the use of digital twins and digital threads for test and evaluation to support iterative product development," that none of the selected Army strategies did either, and that the Navy ones did not. Read that carefully, because it is easy to over-read in both directions. It is a purposive sample of eight programs, and GAO narrowed its selection toward programs identified as potentially using modern design tools, so the sample was biased toward adopters and still returned none. But the finding is about considering twins for iterative test and evaluation, not about whether twins exist at all: GAO explicitly notes that FLRAA intends to use digital tools, just not in an iterative test approach. GAO also went after the policy itself, finding that "DOD's digital engineering policy and the test and evaluation section of DOD's systems engineering policy do not describe specific processes to ensure application of leading practices to testing."

The quietest finding in that report is the one program managers should tape to the wall. GAO found the Army strategies "generally did not advocate for government access to contractor-developed digital twins and digital threads." A model can exist, be excellent, and be useless to the government, because the data rights were never bought.

If you have neither a clearance nor a budget

You can still learn four of the five altitudes. Eclipse Capella is EPL-2.0, at version 7.1.0 as of July 2026, and used at Rolls Royce, ArianeGroup and CNES. It is not free Cameo, and pretending otherwise will hurt you: Thales built both Capella and the Arcadia method behind it and deliberately chose a domain-specific language over SysML, because "Arcadia/Capella primarily focuses on the design of systems architectures" while SysML is general-purpose. It teaches the shape of the altitude, not the notation. At the dynamics altitude the honest free analogue is OpenModelica, with FMI as the bridge back to the commercial stack. GNU Octave and SciPy cover the MATLAB language and numerical analysis respectively, but neither is a Simulink substitute: Octave's own site hedges that it is "drop-in compatible with many Matlab scripts," and neither has a block-diagram environment or a production code generator.

MathWorks lists the Standard Individual commercial license at 940 dollars per year as the page returned it in July 2026. The other four tools publish no prices at all, so any dollar figure you see for the enterprise stack was made up by somebody. And the fifth altitude you cannot practice at any price. That is the accurate answer.

The ledger reading

The five boxes are a fair map of the altitudes. What the map hides is that the arrows are not infrastructure. They are projects: a technology preview that syncs one way, a feature whose name promises coupled solvers and whose documentation admits atomic invocation, a free standard reached through a paid door, and a C++ plugin you will write yourself against documentation you may not be allowed to read.

None of that means the toolchain is a fraud. It means the thing sold as connective tissue is the thing to budget for, staff for, and test first, because it is the least finished part of the stack and the part every diagram draws as a line. INCOSE said so in 2007. The vendors' own documentation says so today, in the pages nobody reads because the datasheet was easier. Read the docs, not the datasheet. When they disagree, the docs are the ones with the bug list, and the bug list is the honest document.

Related reading

• Jama Connect: The Trace Matrix Is Gone, and So Is 21 CFR 820.30: the requirements altitude on its own, and what its coverage score actually measures.
• Cameo Systems Modeler, CATIA Magic, and the MBSE Benefits Nobody Measured: the architecture altitude, the rename, and the evidence problem underneath MBSE.
• MATLAB: What It Actually Is, and Why Almost Every Article About Its Price Is Now Wrong: the algorithm altitude and what the licensing actually costs now.
• Simulink and Model-Based Design: There Is No Such Thing as a DO-178C Certified Code Generator: the dynamics altitude and how a model becomes a certifiable artifact.
• AFSIM: How the Air Force Ended Up Owning Boeing's Simulation Framework: the mission altitude, its origin, and the export-control wall around it.

Fact-check notes and sources

• The 2018 DoD Digital Engineering Strategy contains "digital twin" zero times, "digital thread" once (in an A-10 case study), and "authoritative source of truth" 53 times; MBSE, SysML, MATLAB, Simulink and V-model appear zero times; the five goals and the ASoT definition: term counts obtained by extracting the text of the official PDF directly. Counts for "authoritative source of truth" and "digital thread" are stable across extraction engines; a count for "digital engineering" itself is not quoted here because it varies (roughly 126 to 145) depending on whether a decorative running header is counted as body text.
• DoD Instruction 5000.97, published December 21, 2023, and the official definitions of digital twin, digital thread, digital model, digital artifacts and the digital engineering ecosystem: the OUSD SE&A January 2026 summary info sheet, which still lists the instruction as published on that date. The full instruction itself is not reachable at any public mirror I could open, so every claim here about it is sourced to DoD's own published summary of it, not to the instruction text. The digital model definition is quoted in part; it continues "May include form, attributes, and functions and may be depicted visually or as a mathematical or logical expression." Note also that the January 2026 sheet says "Department of War (DoW)" throughout while still calling the policy a DoD Instruction. As of July 2026 that is not an error to smooth over: Executive Order 14347 (September 5, 2025) authorizes "Department of War" as a secondary title for non-statutory use within the executive branch, and Section 2(e) states that "statutory references to the Department of Defense, Secretary of Defense, and subordinate officers and components shall remain controlling until changed subsequently by the law."
• The NASA and Air Force Office of Scientific Research 2012 digital twin definition: Glaessgen and Stargel, "The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles", NASA NTRS. The Digital Twin Consortium definition (published December 3, 2020) is quoted from the Capabilities Periodic Table User Guide.
• The Kritzinger taxonomy (digital model, digital shadow, digital twin, classified by manual, one-way automatic, and bidirectional automatic data flow): Kritzinger et al. (2018), IFAC-PapersOnLine 51(11):1016-1022, DOI 10.1016/j.ifacol.2018.08.474, confirmed via the Fraunhofer repository record. The publisher's full text is captcha-gated, so the taxonomy is paraphrased and attributed rather than quoted. Its use inside defense T&E: ITEA Journal of Test & Evaluation, Vol. 45-1 (March 2024).
• The 15,000-publication definitional study: Abdelrahman et al. (2025), Building and Environment 274:112748; the quote is taken from the accepted manuscript, which may differ from the published version. The study also drew on a prior Delphi survey of 52 experts that the authors built on rather than ran themselves.
• "Two thirds of claimed MBSE benefits are only supported by perceived evidence, while only two papers reported measured evidence": Henderson and Salado (2021), Systems Engineering 24(1):51-66, DOI 10.1002/sys.21566, abstract via RePEc and corroborated at the University of Arizona repository. The paper's conclusion is that evidence is inconclusive, not that MBSE fails.
• The MBSE inhibitors named in 2007: INCOSE Systems Engineering Vision 2020, INCOSE-TP-2004-004-02, September 2007. The odd spacing in "model /data exchange" is INCOSE's, reproduced as printed.
• GAO's December 2025 findings on digital twins in test and evaluation, the policy critique, the Army data-rights finding, and the recommendation tally: GAO-26-107009. The sample is eight programs (T-7A, F-22, F-35, IVAS, XM30, FLRAA, CVN 78, Ship to Shore Connector), selected partly for whether they were identified as potentially using modern design or test approaches. The finding is that these strategies did not consider twins for iterative test and evaluation, which is narrower than "no program uses a twin." A separate June 2025 report, GAO-25-107569, found that few of the programs it reviewed reported plans to use digital twinning or digital threads; GAO published no exact count on the product page and its full PDF is not publicly reachable, so no number is stated here.
• AFSIM's origin, naming, altitude span, and access restrictions: CSIAC's AFRL-authored overview for the Boeing AFNES history, the roughly 35 million dollars of independent research and development funding, the 2013 transfer with unlimited rights, the span quote, and the fidelity quote; DSIAC for the export-control statement, the Distribution Statement F and C markings, and the ITA/MOU access path. No first-party AFSIM to Simulink FMI bridge is documented in any public source I could find. That is a statement about the public record, not a claim that none exists: AFSIM's documentation is Distribution Statement C, so this is not verifiable either way from outside.
• The Jama and Cameo connector contradiction: Jama's September 2024 datasheet against Dassault's Cameo DataHub 2024x documentation and 2024x Refresh2 version news. No documentation space for a 2025x or 2026x release was found, so "as of the newest publicly documented release" is doing real work in that sentence. The third-party and OSLC routes: Jama's own Syndeia walkthrough and Intercax Syndeia.
• "Simulink co-simulation" executing the whole model atomically, and the MATLAB Evaluator integration with its JDK coupling: Cameo Simulation Toolkit 2024x and 2024x Refresh2 documentation.
• FMI 3.0.2 as the current release, roughly 280 tools across all versions, and the three interface types: fmi-standard.org and the 3.0.2 specification. The count spans all FMI versions; an FMI 3.0-specific tool count is not published. FMU import native to Simulink: MathWorks documentation. FMU export as a separate paid product or a support package requiring MATLAB Compiler and Simulink Compiler: Simulink FMU Builder and FMU Builder for Simulink.
• Product names: Dassault's CATIA Magic page for the Cameo rebrand (the vendor's own page uses both "CATIA Magic Cyber Systems Engineer" and "Magic Cyber-Systems Engineer"; both are reproduced as printed), and the Requirements Toolbox page for the R2022a rename. That page's actual digital-thread claim reads "create a digital thread that links requirements, model elements, MATLAB code, data dictionaries, test cases, and test harnesses," and it notes that the Polarion Connector for Simulink "is developed and maintained by Siemens." System Composer for the MathWorks MBSE overlap.
• MATLAB pricing at 940 dollars per year for a Standard Individual commercial license: the MathWorks pricing page as it returned in July 2026. That page is dynamic and region-sensitive, and secondary sources circulate different figures. No list prices are published for CATIA Magic, Jama Connect or Cameo DataHub.
• Free alternatives: Eclipse Capella (EPL-2.0, v7.1.0, July 10, 2026) and Bonnet and Rochet on why Capella is not a SysML tool; OpenModelica; GNU Octave; SciPy.

This post is informational and journalistic, describing publicly documented tools, standards, and government reports. It is not engineering, procurement, or compliance advice. I have no affiliation with, and nothing here is endorsed by, any product, vendor, or organization named; all are discussed from public records and their own published statements as nominative fair use. Product names, versions, prices, and policy details are current as of mid-2026 and change.