prEN 9300-500

SLOVENSKI STANDARD
01-december-2025
Aeronavtika - LOTAR - Dolgotrajno arhiviranje in iskanje digitalne tehnične
dokumentacije o izdelkih, kot so podatki o zahtevah, arhitekturi, simulacijah in
analizi - 500. del: Osnove in pojmi za dolgoročno arhiviranje, ki omogočajo
modelno zasnovano sistemsko inženirstvo
Aerospace series - LOTAR - Long Term Archiving and Retrieval of digital technical
product documentation such as requirements, architecture, simulation, and analytical
data - Part 500: Fundamentals and Concepts for Long Term Archiving to enable Model-
based Systems Engineering
Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung und Bereitstellung digitaler
technischer Produktdokumentationen, wie Anforderungen, Architektur, Simulation und
analytische Daten - Teil 500: Grundlagen und Konzepte für die Langzeit-Archivierung zur
Ermöglichung modellbasierter Systementwicklung
Série aérospatiale - LOTAR - Archivage à Long Terme et Récupération de la
documentation numérique techniques des produits tels que les exigences, l’architecture,
la simulation et les données analytiques - Partie 500 : Principes fondamentaux et
concepts de l’archivage à long terme pour permettre l’ingénierie des Systèmes basée
sur des Modèles
Ta slovenski standard je istoveten z: prEN 9300-500
ICS:
35.240.30 Uporabniške rešitve IT v IT applications in information,
informatiki, dokumentiranju in documentation and
založništvu publishing
49.020 Letala in vesoljska vozila na Aircraft and space vehicles in
splošno general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2025
ICS 01.110; 35.240.30; 35.240.60; 49.020
English Version
Aerospace series - LOTAR - Long Term Archiving and
Retrieval of digital technical product documentation such
as requirements, architecture, simulation, and analytical
data - Part 500: Fundamentals and Concepts for Long
Term Archiving to enable Model-based Systems
Engineering
Série aérospatiale - LOTAR - Archivage à Long Terme et Luft- und Raumfahrt - LOTAR - Langzeit-Archivierung
Récupération de la documentation numérique und Bereitstellung digitaler technischer
techniques des produits tels que les exigences, Produktdokumentationen, wie Anforderungen,
l'architecture, la simulation et les données analytiques Architektur, Simulation und analytische Daten - Teil
- Partie 500 : Principes fondamentaux et concepts de 500: Grundlagen und Konzepte für die Langzeit-
l'archivage à long terme pour permettre l'ingénierie Archivierung zur Ermöglichung modellbasierter
des Systèmes basée sur des Modèles Systementwicklung
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee ASD-
STAN.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 9300-500:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
1.1 In Scope . 7
1.2 Out of Scope . 7
2 Normative references . 8
3 Terms, definitions and abbreviations . 8
4 Applicability . 8
5 Business specifications for archiving and retrieving MBSE entities . 8
5.1 MBSE Process and Use Cases . 8
5.2 MBSE Use Case Examples . 10
5.2.1 General . 10
5.2.2 User Viewpoint . 10
5.2.3 Company Viewpoint . 11
5.2.4 Use Case for Requirements Management (P510) . 11
5.2.5 Use Case for Verification and Validation (P515) . 12
5.2.6 Use Case for Analytical Behaviour Model (P520) . 13
5.2.7 Use Case for System Architecture Descriptions (P530) . 14
5.2.8 Use Case for Logical Bill-of-Materials (P540) . 15
5.2.9 Use Case for highly integrated and interrelated models (P550) . 16
6 Essential MBSE Information and data . 17
6.1 General . 17
6.2 Applying basic EN 9300 principles . 18
6.3 Using STEP – Product data representation and exchange . 20
6.4 Data preservation is justified by business needs . 21
6.5 Identification of essential information . 21
6.6 Data retention during the Product Lifecycle . 22
6.7 MBSE data retention milestones . 23
6.7.1 General . 23
6.7.2 Identifying mature data . 24
6.7.3 Data Maturity Status . 25
6.8 Domain Representations for Archival and Retrieval . 26
6.9 Guidelines for implementing an MBSE archive . 27
6.9.1 General . 27
6.9.2 Data preservation planning. 27
6.9.3 Archiving Configured Baselines . 27
6.9.4 Process Documentation . 28
6.9.5 Essential Data in Relation to Business Scenarios to Be Supported . 28
7 Verification and Validation (V&V) of MBSE models . 29
7.1 Implementing V&V. 29
7.1.1 General . 29
7.1.2 V&V Rules for MBSE Information . 29
7.1.3 The Application of V&V Rules . 29
7.2 Verification Rules for Archiving MBSE Information . 30
7.2.1 General . 30
7.2.2 Content verification . 31
7.2.3 Package verification . 31
7.2.4 Verification level 1 – Mandatory rules . 31
7.2.5 Verification level 2 – Mandatory plus optional rules . 32
7.3 Validation rules for MBSE Information. 32
7.3.1 General . 32
7.3.2 Levels of Validation . 33
7.3.3 Validation Level 1 – Mandatory rules . 33
7.3.4 Validation Level 2 – Mandatory plus optional rules . 33
7.4 Verification and validation steps during the MBSE model archiving process . 34
7.4.1 General . 34
7.4.2 Model creation . 34
7.4.3 Model Archiving . 35
7.4.4 Model Storage . 36
7.4.5 Model Consulting . 36
7.4.6 Model Retrieval . 36
7.4.7 Model Consumption . 36
8 Preservation planning for archived MBSE information . 36
8.1 General . 36
8.2 The Model Manifest and Report . 37
8.3 The Process Workflow . 37
8.3.1 General . 37
8.3.2 The Workflow Overview . 39
8.3.3 The Process Roles . 39
8.4 The Model Manifest . 39
8.4.1 General . 39
8.4.2 Manifest Rules . 40
8.5 The Model Report . 40
8.5.1 General . 40
8.5.2 Model Report Rules . 40
8.6 Designating the Credibility and Coherence of MBSE Information . 41
8.7 Create an Implementation Package: The Logical Bill-of-Material (LBOM) . 41
8.8 Managing Links to external MBSE Information . 42
8.9 Alternative Designs for archiving MBSE information . 42
8.10 Identifying risks for long term archiving of MBSE Information . 43
9 Evolution of MBSE data standards . 43
10 Definition of Archive Information Packages for MBSE Data . 44
10.1 General . 44
10.2 Content Information . 44
10.3 Preservation Description Information . 45
Annex A (informative) Model Metadata . 47
Annex B (informative) Model Report . 53
Annex C (informative) Glossary . 59
Bibliography . 61
European foreword
This document (prEN 9300-500:2025) has been prepared by ASD-STAN.
After enquiries and votes carried out in accordance with the rules of this Association, this document has
received the approval of the National Associations and the Official Services of the member countries of
ASD-STAN, prior to its presentation to CEN.
This document is currently submitted to the CEN Enquiry.
Introduction
This document was prepared jointly by AIA, ASD-STAN, PDES, Inc., and the prostep ivip association.
The prostep ivip association is an international non-profit association in Europe. For establishing
leadership in IT-based engineering it offers a moderated platform to its nearly 200 members from leading
industries, system vendors and research institutions. Its product and process data standardization
activities at European and worldwide levels are well known and accepted. The prostep ivip association
sees this document and the related parts as a milestone of product data technology.
PDES Inc. is an international non-profit association in the USA. The mission of PDES Inc. is to accelerate
the development and implementation of ISO 10303 standards, enabling enterprise integration and PLM
interoperability for member companies. PDES Inc. gathers members from leading manufacturers,
national government agencies, PLM vendors and research organizations. PDES Inc. supports this
document as an industry resource to sustain the interoperability of digital product information, ensuring
and maintaining authentic longevity throughout their product lifecycle.
Readers of this document should note that all standards undergo periodic revisions and that any
reference made herein to any other standard implies its latest edition, unless otherwise stated.
The LOTAR Standards are published by two different standards organizations using different prefixes.
ASD-STAN publishes the standard under the European Norm (EN), number EN 9300–xxx. AIA publishes
the standard under the National Aerospace Standard (NAS), number NAS9300–xxx. The content in the
EN 9300 and NAS9300 documents are virtually the same. Differences are noted in the reference
documentation (i.e. for EN 9300 Geometric Dimensioning and Tolerancing are referenced in
ISO 1101 [32] and ISO 16792 [37], and for NAS9300 the same information is referenced in
ASME Y14.5 [40] and ASME Y14.41 [41]). The document formatting, etc., follows the respective editorial
rules of ASD-STAN and AIA.
This document specifies the fundamentals and concepts for the long-term preservation of digital
products and technical data. EN 9300 is a series of separate standard parts that elucidate various
regulatory and business requirements, applicable domain specific methodologies and are extensible for
future long-term archiving formats and data management practices.
The focus of this document is on the fundamentals and concepts of Long-Term Archival and Retrieval of
digital Product and Technical data as applied to Model-based Systems Engineering information. See
Annex C for common acronyms and terms.
In this document, the following verbal forms are used:
— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission;
— “can” indicates a possibility or a capability.
This document is based on the principle that major changes are occurring in the Systems Engineering
technologies, and that new integrated applications are producing digital models that replace the
historical Systems Engineering representations comprised of documentation, tables and graphics. MBSE
is an activity that uses the software tool applications. ISO/IEC/IEEE 24641, Systems and Software
engineering — Methods and tools for model-based systems and software engineering [4] is a formal high-
level description of the MBSE process, specific tasks and tool capabilities.
As defined by INCOSE, MBSE is the formalized application of modelling to support system requirements,
design, analysis, verification and validation activities beginning in the conceptual design phase and
continuing throughout development and later lifecycle phases [30].
Consider the different generations of Systems Engineering data and associated methods of design:
— The first generation of Systems Engineering design methods allowed the engineer to create text-
based documents (without a model) using office automation tools. The essential information as well
as the Regulatory authority of the design intent were represented and preserved using documents
(printed or archived in a digital text/tabular format).
— The second generation of Systems Engineering design methods was based primarily on the
combination of digital documents and supporting mathematical models. The Regulatory authority of
the design intent was represented by documents.
— The third generation of Systems Engineering design methods is based on the use of models, their
underlying relationships, and direct or inferred associations. Documentation supplements the
integration of the models, and specialized databases manage the design implementations. The
authoritative models can represent the essential information as well as the Regulatory authority of
the design intent.
Based on the INCOSE System Engineering 2025 Vision, Model-based Systems Engineering will become
the “norm” for systems engineering execution, with specific focus placed on integrated modelling
environments [19].
As recommended in the INCOSE System Engineering 2035 Vision the necessary changes include,
“Systems Engineering Adoption of Reuse Practices” [20]. To facilitate reuse, a MBSE environment will
implement the following standard processes:
— commonality of practice across a range of systems engineering use cases is understood and applied;
— patterns and unified models that account for variations are established;
— effective reuse practices evolve and become widely applied across domains (Product Line
Engineering and Composable Design).
A system is an integrated set of elements, subsystems, or assemblies that accomplish a predefined
objective. These elements include products (hardware, software, and firmware), processes, people,
information, techniques, facilities, services, and other support elements. Configuration Management in a
Systems Engineering context is fundamental to maintaining the relationship between models and the
related data. The purpose of this document is to identify the preferred process for archiving System
Engineering digital models for future retrieval. The INCOSE Vision statements reinforce this objective.
1 Scope
1.1 In Scope
The EN 9300-5xx series specifies the methods for long term archiving and retrieval of MBSE data
represented as digital models. The characterization of models that are considered in scope of this
document and the MBSE process use cases include:
— product or system design requirements models;
— functional architecture models;
— logical architecture models (system structure, arrangement, connectivity, software allocations and
controls, and part relationships);
— numerically-based system analysis and simulation models, generally regulated 1D control loop
models featuring system components and transport elements (tubing, piping, signalling, software);
— verification and validation of requirements;
— protocol dependent signal or communication networks;
— multi-model linking and system parametric models;
— system trade study models;
— the solution architecture models and data that are needed to implement the system and generate
system engineering data for downstream designs.
1.2 Out of Scope
The EN 9300-5xx series does not address the original product model design process, or a specific
configuration management process for the LOTAR archive. It does not address models depicting part
specific technical data (physical materials or detail part standards). It is assumed that these archiving
processes are within the scope of other parts of the EN 9300 series such as the 1xx series for CAD, the 2xx
series for Product Data Management (PDM) data, or by applying existing alternative industry standards,
or existing company business procedures.
Typical models and capabilities considered out of scope of this document include:
— physical spatial models or composite structures (as described by other LOTAR Parts);
— Finite Element and CFD models (as described by other LOTAR Parts);
— Product Data Management models (as described by other LOTAR Parts);
— electrical circuit boards, or physical wiring parts or systems (described by other LOTAR Parts or
standards);
— the software development process and software models that are outside of the context of software
parts, behaviours, or functions that represent software code within a model;
— how to preserve property and access rights, or government acquisition-regulatory controls;
— new standards, or major revisions to existing MBSE standards that were not available or applicable
prior to the publication of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 9300-007, Aerospace series — LOTAR — LOng Term Archiving and Retrieval of digital technical product
documentation such as 3D, CAD and PDM data — Part 007: Terms and definitions
ISO 16363, Space data and information transfer systems — Audit and certification of trustworthy digital
repositories
3 Terms, definitions and abbreviations
For the purpose of this document, the terms and definitions given in EN 9300-007 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
4 Applicability
Since MBSE technical product information is intended to be generated, exchanged, and used digitally;
rules governing model architecture, application technology, modelling processes, data formats, and
language options need to be adapted and standardized to enable digital retention and long-term
archiving. The EN 9300 series closes this gap as a standard for long-term archival and retrieval of model-
based product data. Basic applicability rules are specified in EN 9300-001 “LOTAR Structure” [43].
5 Business specifications for archiving and retrieving MBSE entities
5.1 MBSE Process and Use Cases
MBSE embraces a wide range of lifecycle steps and an equally wide range of engineering models. Adding
to this lifecycle complexity, multiple modelling standards will need to be considered to adequately
capture all of the relevant MBSE information. Therefore, a single use case will not embrace all aspects of
MBSE. In this document, the specific sub-parts of P500 (listed below) are generally referred to as P5xx.
The P5xx subparts represent the basic Systems Engineering subdomains and deliverables that comprise
MBSE models and information.
— Part 500: Fundamentals and Concepts for long term archiving and retrieval of Model-Based Systems
Engineering information.
— Part 510: Long term archiving and retrieval of Requirement management text, graphics, tables,
models, and “parameter based” information.
— Part 515: Long term archiving and retrieval of Validation and Verification “text based” and
“parameter based” information (expanding Part 510).
— Part 520: Long term archiving and retrieval of system or component level analytical behaviour
models described by specification or executable code, containing differential, algebraic and discrete
equations. Includes causal or acausal models not addressed by the Part 600 series.
— Part 530: Long term archiving and retrieval of models that use system architecture descriptions and
architecture description languages (ADLs) specified by ISO/IEC/IEEE 42010 [8], and
SAE AS5506 [42].
— Part 540: Long term archiving and retrieval of data and models specifying the Logical Bill of
Materials (LBOM), and the physical implementation specifications required for Model-based 3D
Engineering and Product Manufacturing.
— Part 550: Long term archiving and retrieval of models or features describing digital or relational
links. Methods for specifying highly integrated and interrelated models and elements across
numerous software tool applications.
The Basic LOTAR use cases:
— how to archive the relevant product data for preservation;
— how to retrieve, verify and reuse the archived information.
The Extended LOTAR use cases:
— the ability to maintain the data used for certification;
— the ability to support regulatory agency requirements, and investigations;
— the ability to reuse/migrate design information to new products;
— the ability to serve other aspects of the business lifecycle. This generally includes legal, product
support, future product modifications, and part/design obsolescence.
MBSE use case considerations for LOTAR:
— the ability to archive, retrieve, and reuse the system engineering models and context data that is
exchanged between users, organizations, or across an enterprise;
— the ability to archive, retrieve, and reuse the system engineering models and context data exchanged
across a supply chain;
— the ability to archive and retrieve design requirements and the information depicting their allocation,
constraints, analysis and relationships relative to other design domains;
— the ability to archive and retrieve the data that represents the Verification and Validation process
and results that was applied to the product design data;
— the ability to archive and retrieve information identifying what system elements, attributes, and
parameters are applicable to a set of models and their relationships;
— the ability to archive and retrieve MBSE information that will be disseminated, consumed and
integrated by downstream design, manufacturing and product support teams.
5.2 MBSE Use Case Examples
5.2.1 General
The following activity diagrams are intended to represent the LOTAR perspective of the MBSE model
creators, and the model owners (Company), for each sub-part in the P5xx series. The system engineering
process descriptions are not included because the use cases describe the high-level activities for the data
author. Additional Use Cases may be applicable and specified by the users of this document.
5.2.2 User Viewpoint
Figure 1 illustrates the generic activities of a Model-based Engineering (MBE) software application tool
user. Variations for specialized MBSE modelling domains are explored in subsequent figures. Multiple
software application tools may be used, each generating unique data formats.
A designer or systems engineer receives a work request applicable to a design with an existing
configuration baseline. After identifying and evaluating the design requirements, they will search the
model archive repositories for reusable design data and information. Based on the results they will either
reuse or modify an existing model, or create a new one using Model-based Engineering (MBE) tools. In
compliance with company policy, they will define a data preservation plan for all revised or new
information. During the early stages of modelling, configuration information is applied to each artefact,
and they will initiate or update the model manifest. Before publishing the results, the modelling
requirements are verified, the model quality is calculated, and the preservation plan is completed. In most
cases, they will also generate a model summary or report.

Figure 1 — LOTAR Use Case Diagram for MBSE Users
5.2.3 Company Viewpoint
The company, or governing entity representing your organization, creates or modifies existing products
to address current market needs. Based on a product strategy the company specifies reuse initiatives, a
configuration management plan, and a process for creating the product definition, and a manufacturing
plan. The plans to define and manufacture the product include MBSE methods and extend to the supply
base. The reuse of existing design and manufacturing information is key to the product’s affordability and
the market’s expectations. Configuration management, data standards and compatible tools are needed
to ensure that the product strategy is executed and that the archive packages remain usable and
modifiable for future use. As depicted in Figure 2, the Company Teams are responsible for executing the
product strategy. They utilize the archived data to both create and extend the use of existing models.
Team members share those results when negotiating the solutions outsourced to suppliers. The benefits
and advantages of MBSE data reuse begin with the initial product trade studies, carry through the
manufacturing process, and continue to multiply into the delivery and product support lifecycles.

Figure 2 — Use Case Diagram for LOTAR Environment (Company Viewpoint)
5.2.4 Use Case for Requirements Management (P510)
A Requirements Engineer should understand the customer’s needs and the company’s product strategy
in order to define and model a set of product requirements. A requirements team should endeavour to
examine and reuse existing sets of requirements by consulting all available archives. Updates to the data
preservation plan should be contributed for all reusable information that is revised or created. To execute
the process, a requirements team will transform the stakeholder’s operational needs and the company’s
product strategy into models characterizing the product’s functional, logical, and technical requirements.
A requirements team will support a change and configuration management process as the requirements
mature, and also create and evaluate a requirements validation plan. The plan will ensure that all
requirements are allocated, consumed and traceable, including any implied dependencies. A
requirements team will maintain and update the body of requirements until the product is delivered, and
as illustrated in Figure 3, all of the information will be available in the company’s data archive for future
reuse.
Figure 3 — Use Case Diagram for Requirements Management (P510)
5.2.5 Use Case for Verification and Validation (P515)
The Verification and Validation (V&V) Engineer needs to understand how the product and design
requirements were specified, allocated and implemented in the MBSE models. By analysing the models
and working with the design teams, they can specify a requirements verification process to evaluate the
correctness and completeness of the applied-derived-decomposed requirements, how they were
characterized in the models, and how the model results were substantiated and documented in the model
summary reports. If any of the models were previously archived, they shall review any preceding
archived reports and V&V evidence. Generally, the V&V process is iterative and should be applied to
multiple models stored on various computing platforms, that collectively represent a system. When
developing a verification plan, product functionality will be considered and design requirements will be
validated. The verification results will lay the foundation for the subsequent design assurance analysis
and performance tests included in the validation plan. The process includes, collaborating with the test
engineers and developing validation plans to support their component and product testing. The V&V
process results will be documented in models, integrated into a preservation plan, and maintained within
the product configuration baseline. As illustrated in Figure 4, all of this information will be made available
to the company’s data archive.
Figure 4 — Use Case Diagram for Verification and Validation (P515)
5.2.6 Use Case for Analytical Behaviour Model (P520)
The Analysis Engineer creates simulation models based on mathematical specifications and differential
equations. In alignment with the company’s strategy, they will substantiate, decompose and verify design
requirements allocated to a system architecture. The engineer will test system functions and software
code, conduct trade studies, and develop product/part specifications and tolerances. Models are also used
to validate behaviours, and evaluate safety concerns. Once the scope of the work assignment is received
and understood, the engineer will consult the archived studies and models to search for relevant data.
When a new model is required, a metadata manifest is developed by describing the model’s data, the
software application and the operating system. To keep the models synchronized with upstream changes,
application links are created to the system architecture and requirements data. Collaboration with the
design and verification engineers is necessary to consider their needs and expectations when the data
preservation plan is created. Verification and credibility tests are performed after each model is created.
As illustrated in Figure 5, the test results are summarized in a model report that captures the process
steps, assumptions and potential risks. All of this information becomes part of the archive package that
will be added to the company’s model archive repository.
Figure 5 — Use Case Diagram for Analytical Behaviour (P520)
5.2.7 Use Case for System Architecture Descriptions (P530)
A System Architect should understand the system’s purpose, domain, stakeholder requirements, and
basic operation to specify an implementation architecture that can deployed and reused. Following
receipt of a work-design request the system context is defined. To understand the system’s purpose, the
architect should evaluate the operational environment and the models created by the requirements team.
This information will support queries of the system archives for previous models, schematics, and
approaches to managing the structure, energy and signals of similar systems. In most cases the initial
models will decompose a foundation of stakeholder and operational requirements into functions to
establish my base system and primary interfaces to other systems. Then the interfacing components
expose a logical structure that will evolve into a logical implementation of system technical requirements.
The architect works closely with the simulation, verification, and safety engineers, considering their
needs and deliverables as models are developed and added to the data preservation plan. A complex
system may require multiple models and configuration management begins with their earliest
renderings. To streamline integration with other system models, it is recommended to extend the
metadata within a SysML model to facilitate its eventual extraction as a model manifest before archiving.
As illustrated in Figure 6, the model quality, verification, and preservation plan assessments are
completed before committing the models for final publication and their eventual submittal to the
company’s archives.
Figure 6 — Use Case Diagram for the System Architecture Definition (P530)
5.2.8 Use Case for Logical Bill-of-Materials (P540)
The Implementation Engineer should clearly present all of the design information representing a system
of interest. This is accomplished by capturing the system design specification in Logical Bill-of-Materials
(LBOM) packages to clarify the downstream technical requirements. Each package contains models,
tables or documents that will be either extracted from the reuse archives or created by the system design
teams. The contents of each package shall be consumable by the downstream suppliers, engineering and
manufacturing organizations. The consumers include the engineers creating the geometric spatial
definition, manufacturing planners, the component and software suppliers, the assembly and installation
planners, test engineers, quality technicians, product utilization planners, and the product support teams.
Each package represents a logical bill-of-material (LBOM), and will be created for every functional system
encompassing the final product. To provide downstream consumers access to latest design information,
the packages will be managed within a configuration baseline that matures during the system
development lifecycle. To create and keep the packages up-to-date, requires continuous collaboration
with the system engineering design teams. The packages will include traceable links to the source models,
information standards, and specification information. As illustrated in Figure 7, a data preservation plan
ensures the LBOM information is identifiable and available in the long term archives. For more
information, see 8.7.
...