LOTAR's own project report makes a point that should make any model owner a little uneasy: in aerospace there can be about 80 years between the initial design of a program and the end of life of the last aircraft delivered. Now think about the system model your team is building today. Will anyone be able to open it in 2090? Will the tool exist? Will the file even parse?
Most MBSE conversations stop at "we have a model." Far fewer ask what happens to it when the program office closes, the vendor changes hands, or a certification authority asks a question twenty years later.
What LOTAR is, and why MBSE showed up in it
LOTAR (Long Term Archiving and Retrieval) is a joint project under AIA and ASD, with PDES, Inc. and prostep ivip. It develops and maintains the EN/NAS 9300 series of standards for archiving digital product and technical information. Participants listed by prostep ivip include Airbus, Boeing, Embraer, GE, Gulfstream, Leonardo, Lockheed Martin and Raytheon Technologies.
The series started with CAD and product data, and has grown to cover composites, wire harnesses, CAE simulation data and, now, MBSE artifacts. The stated goal is simple: archived data stays readable and reusable even when the original IT environment is long gone.
That last clause is the whole problem. A SysML model saved in a vendor's project format is only as durable as that vendor's software.
What prEN 9300-500 actually covers
Part 500 is titled "Fundamentals and Concepts for Long Term Archiving to enable Model-based Systems Engineering." According to the standards listing, it was at the close-of-voting stage (stage 40.60) with voting closing January 15, 2026. I couldn't confirm a final publication date, so check the current status before you cite it in a contract.
The scope is broader than "the SysML file." It names these kinds of MBSE data:
- Requirements models and the verification and validation of those requirements
- Functional and logical architecture models, including structure, connectivity and software allocations
- Numerical analysis and simulation models, such as 1D control loop models
- Multi-model links and system parametric models
- Trade study models and solution architecture models
Explicitly out of scope: CAD part models, finite element and CFD models, PDM models, electrical circuit and wiring models, and software development processes. Those belong to other parts of the series.
The LOTAR 2025 report adds some texture. The MBSE group's 2025 deliverables included a demonstrator called Stratoliner, integration of the MIC-core with the LOTAR manifest, and continued work on a validation tool for archive packages. For 2026 it plans internal drafts of Part 515 (validation and verification requirements) and Part 520 (analytical models described by specifications or executable code and equations). The group also works with INCOSE and OMG's CASCaRA initiative.
Why a model file isn't an archive
Here's the practical gap. A model file tells you what the model says. An archive has to let someone else, later, confirm it still says it, and understand it without you in the room.
Think of it in layers. At the bottom, integrity: a manifest of what's in the package and a way to validate it (this is the idea behind LOTAR's archive package validation work). Above that, a neutral format that doesn't depend on a running copy of the authoring tool. Then the model content itself. On top, the context: which requirements version it traced to, which analysis results it produced, and why the decisions were made.
Most teams do the third layer and skip the other three.
What you can do now, before the standard settles
You don't need to wait for a final Part 500 to improve your odds. A few habits help whatever the standard ends up requiring.
- Export to an open, textual form on a schedule. SysML v2 has a standard textual notation and a standard API, which gives you something readable without the authoring tool. Tools that can emit it include Cameo and CATIA Magic (2026 bundles), the open-source SysON editor, and Dalus. Test that an export loads in a second tool, not just the one that made it.
- Archive baselines, not just the head. Certification evidence usually points at a specific release. Freeze the model state that matched each review gate.
- Keep the evidence next to the model. Simulation inputs, solver versions, verification results and the requirement links. A model without its analysis results is half a record.
- Record the toolchain. Tool names, versions, profiles, libraries. Future readers will want to know what you used.
- Write down the rationale. Decisions don't live in the model. Put the reasoning in a document that travels with it.
What this won't solve
Archiving standards describe how to package and retrieve data. They don't make a poorly structured model understandable. A model with inconsistent naming, undocumented conventions and ten years of dead branches will be a well-preserved mess.
There's also a coverage limit. Part 500 as scoped leaves out CAD, FE and CFD models, so a full system record still means stitching several parts of the series together, plus linking across them. LOTAR's own 2025 report lists persistent identifiers and cross-domain interoperability as open themes for the digital thread, and its Q2 2026 workshop summary says the same.
Finally, the standard is aimed at aerospace and defense primes. If you work in another domain, nothing forces you to adopt it, and your retention obligations may be shorter. The ideas still transfer. Cost and effort are real too: capturing context and validating packages takes time, and nobody gets credit for it until the day it's needed.
The bottom line
If your program lives longer than your tool vendor's roadmap, you need an archiving plan for the model, and "keep the project file" isn't one. Read the scope of prEN 9300-500 even if you're not in aerospace, because it's the clearest public list yet of what a durable MBSE record contains. Then start with the cheap steps: open textual exports, frozen baselines, evidence kept beside the model, and a written toolchain record. You can do all of that this quarter.