ISO/IEC/IEEE 24641:2023
(Main)Systems and Software engineering — Methods and tools for model-based systems and software engineering
Systems and Software engineering — Methods and tools for model-based systems and software engineering
This document deals with the tool capabilities and methods for model-based systems and software engineering (MBSSE). This document: — specifies a reference model for the overall structure and processes of MBSSE-specific processes, and describes how the components of the reference model fit together; — specifies interrelationships between the components of the reference model; — specifies MBSSE-specific processes for model-based systems and software engineering; the processes are described in terms of purpose, inputs, outcomes and tasks; — specifies methods to support the defined tasks of each process; — specifies tool capabilities to automate or semi-automate tasks or methods. This document does not bring any additional life cycle processes for system and software but specifies an MBSSE reference model considered as activities, not only from the life cycle perspectives of systems engineering problem solving and the system-of-interest evolution, but also from the cognitive perspectives of modelling and model management, which can sustain and facilitate the system and software life cycle processes during digital transformation and in the digital age. The processes defined in this document are applicable for a single project, as well as for an organization performing multiple projects or an enterprise. These processes are applicable for managing and performing the systems and software engineering activities based on models within any stage in the life cycle of a system-of-interest.
Ingénierie du logiciel et des systèmes — Méthodes et outils pour l'ingénierie du logiciel et des systèmes basée sur des modèles
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/
STANDARD IEC/IEEE
First edition
2023-05
Systems and Software engineering —
Methods and tools for model-based
systems and software engineering
Ingénierie du logiciel et des systèmes — Méthodes et outils pour
l'ingénierie du logiciel et des systèmes basée sur des modèles
Reference number
© ISO/IEC 2023
© IEEE 2023
© ISO/IEC 2023
© IEEE 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
ii
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
Contents Page
Foreword . vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 8
4 Conformance . 9
4.1 Intended usage . 9
4.2 Full conformance . 10
4.2.1 Full conformance to outcomes . 10
4.2.2 Full conformance to tasks . 10
4.3 Tailored conformance . 10
5 MBSSE reference model .10
5.1 Overview . 10
5.2 Build models processes and data-information-knowledge-wisdom (DIKW) .13
6 Plan MBSSE . .13
6.1 General .13
6.2 Define the scope and objectives of MBSSE. 14
6.2.1 Principal constituents . 14
6.2.2 Establish MBSSE goals and measures . 15
6.2.3 Specify the key elements of the MBSSE approach .15
6.3 Plan model development and governance . 16
6.3.1 Principal constituents . 16
6.3.2 Define MBSSE deployment procedure . 18
6.3.3 Define the MBSSE life cycle flow . 18
6.3.4 Define the MBSSE methodology . 19
6.3.5 Specify how to manage and control the modelling life cycle process . 19
6.3.6 Document the MBSSE management plan . 20
6.3.7 Improve model development and governance process continuously . 21
6.4 Plan resources and assets . . 21
6.4.1 Principal constituents . 21
6.4.2 Define the MBSSE roles, responsibilities, knowledge, skills and abilities
(KSA) . 22
6.4.3 Identify resources .23
6.4.4 Manage modelling assets . 23
6.5 Manage knowledge reuse . 23
6.5.1 Principal constituents .23
6.5.2 Identify model patterns and define meta-models for patterns . 24
6.5.3 Perform commonality and variability analysis . 25
6.5.4 Manage the model repository . 25
6.5.5 Manage knowledge reuse on methods . 26
6.5.6 Manage knowledge reuse on tool extensions . 26
7 Build models .26
7.1 General . 26
7.2 Produce system models . 27
7.2.1 Principal constituents . 27
7.2.2 Collect engineering data .29
7.2.3 Build descriptive models .29
7.2.4 Build analytical models .30
7.3 Produce discipline-specific models . 31
7.3.1 Principal constituents . 31
iii
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
7.3.2 Collect engineering data . 32
7.3.3 Build discipline-specific models . 33
7.3.4 Develop the interfaces between the system models and existing discipline-
specific tools and models . 33
7.4 Verify models .34
7.4.1 Principal constituents .34
7.4.2 Verify models .34
7.5 Validate models . 35
7.5.1 Principal constituents . 35
7.5.2 Validate models .36
7.6 Simulate systems using models .36
7.6.1 Principal constituents .36
7.6.2 Prepare simulation environment with required data and models.38
7.6.3 Simulate systems using models .38
7.6.4 Analyse results and validate behaviours .39
7.7 Make decisions using models .40
7.7.1 Principal constituents .40
7.7.2 Capture decision criteria within the model .40
7.7.3 Generate decision reports . 41
7.7.4 Build a rationale . 41
8 Support models .41
8.1 General . 41
8.2 Manage technical quality . 42
8.2.1 Principal constituents . 42
8.2.2 Perform technical review . 42
8.2.3 Perform quality assurance . 43
8.3 Manage configuration . 43
8.3.1 Principal constituents . 43
8.3.2 Manage modelling assets and configuration items . 45
8.3.3 Manage changes to models . 45
8.4 Manage data and models .46
8.4.1 Principal constituents .46
8.4.2 Define the data and models management policy . 47
8.4.3 Define infrastructure needs to support data and model management . 47
8.5 Share models for collaboration .48
8.5.1 Principal constituents .48
8.5.2 Define collaborative modelling guidelines and environment .49
8.5.3 Define model sharing and authoring rules .49
8.5.4 Maintain the consistency of models .49
9 Perform MBSSE .49
9.1 General .49
9.2 Perform business and mission analysis .50
9.2.1 Principal constituents .50
9.2.2 Describe high-level target enterprise architectures using models . . 51
9.2.3 Evaluate candidate architectures and analyse gaps using models . 52
9.2.4 Establish capability roadmaps . 52
9.2.5 Define business and mission requirements . 52
9.2.6 Generate ConOps .53
9.3 Perform operational analysis .53
9.3.1 Principal constituents .53
9.3.2 Identify system life cycle, boundary and context .54
9.3.3 Identify stakeholders .54
9.3.4 Identify use cases and develop use case scenarios, validation scenarios .54
9.3.5 Identify operational modes . 55
9.3.6 Capture stakeholder requirements and measures of effectiveness (MOEs) .55
9.4 Perform function analysis .56
9.4.1 Principal constituents .56
iv
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
9.4.2 Realize functional analysis and decomposition . 57
9.4.3 Detect or identify possible dysfunctions . 57
9.4.4 Develop functional flows and system states . 57
9.4.5 Capture system requirements, constraints and measure of performance
(MOPs) .58
9.4.6 Realize and manage traceability .58
9.5 Perform system structure design .58
9.5.1 Principal constituents .58
9.5.2 Realize system logical structure . 59
9.5.3 Realize system physical structure .60
9.5.4 Realize and manage traceability .60
9.6 Perform system analysis . 61
9.6.1 Principal constituents . 61
9.6.2 Perform safety or reliability analysis . 61
9.6.3 Perform security analysis . 62
9.6.4 Perform resilience analysis .63
9.7 Perform domain design integration .63
9.7.1 Principal constituents .63
9.7.2 Perform system design modelling .65
9.7.3 Support system integration with the use of models .65
9.8 Perform system verification and validation .66
9.8.1 Principal constituents .66
9.8.2 Prepare model-based verification and validation . 67
9.8.3 Perform model-based verification and validation .68
9.8.4 Manage results .68
Annex A (informative) Instantiation and customization of an MBSSE reference framework .69
Annex B (informative) MBSSE dimensions of a system model .76
Annex C (informative) Models classification and relationships in MBSSE .78
Annex D (informative) Example of MBSSE roles .80
Annex E (informative) Relationships between ISO/IEC/IEEE 24641 and other International
Standards .82
Bibliography .84
IEEE notices and abstract .86
v
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed
for the different types of ISO/IEC documents should be noted. This document was drafted in
accordance with the rules given in the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of
the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see https://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
ISO/IEC/IEEE 24641 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the IEEE Computer Society
Systems and Software Engineering Standards Committee, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
vi
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
Introduction
As systems grow in scale and complexity, some in the systems engineering community turn to model-
based systems and software engineering (MBSSE) to, among other objectives, manage complexity,
maintain consistency, and help ensure traceability during system development. With an MBSSE
approach, the systems and software engineering activities rely on evolving models that serve as the
main or major source of knowledge about the system-of-interest and its life cycle processes, which
could be any entity subject to a system model such as a program, project, product, or company.
MBSSE benefits differ significantly from ‘engineering with models’, which has been a common practice
among the engineering disciplines for decades and that is mainly based on independent discipline-
specific models that, even if very useful for each discipline and system analysis contribution, do not
provide an overall understanding of the architecture of the system sharable among stakeholders,
e.g. computer-aided design (CAD) for mechanical engineering, aerodynamics models, control loop
simulations. In addition, due to the diversity of approaches and terminologies (e.g. model-driven
development or MDD), MBSSE usually falls within the context of a specific engineering discipline (e.g.
MDD for the software engineering community).
MBSSE is the formalized application of modelling to support systems engineering or software
engineering activities. Faced with the issues and challenges linked to the growing complexity of the
systems to be developed, document-centric approaches are less and less suitable. The MBSSE approach
makes it possible to develop logically consistent multi-view architecture description. These serve as
a bridge to enable the traceable, verifiable and dynamic correlation of the system-of-interest and/or
software-of-interest models cross multidiscipline and throughout its entire life cycle, and to drive
the system and software engineering processes, activities and tasks at all levels of its hierarchy from
system-of-systems to system element across multiple engineering disciplines and throughout all stages
of its life cycle
From MBSSE perspective, other engineering disciplines (mechanical, thermal, electronic, electrical,
etc.) are also considered.
Thus, a need exists to specify the considerations necessary for undertaking the application of MBSSE
within an organization. An organization needs to address the considerations necessary for supporting
the establishment of each project environment within its overall ecosystem, and the exchange of models
between stakeholder organizations.
This document addresses MBSSE-related processes by categorizing them into four process groups:
— Plan MBSSE
— Build models
— Perform MBSSE
— Support models
Each process is defined in terms of purpose, inputs, outcomes, and supporting tasks. The task
descriptions include tool and method guidance and the recommended capabilities needed to
successfully implement them. The relationships among the four process groups in this document, the
four process groups in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207, and the life cycle model and
stages in ISO/IEC/IEEE 24748-1 are described in Annex A.
This document is intended to benefit those who acquire, supply, develop, operate, and maintain MBSSE
tools and methods. It can be used by:
a) organizations that need to implement or build models – to understand, adopt, and enact the MBSSE
processes, tools, and methods (it also helps to evaluate and select relevant tools and methods based
on business- and user-related criteria);
vii
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
b) tool vendors who facilitate or leverage MBSSE practices – to provide a set of recommended tool
capabilities for planning MBSSE, building models, MBSSE performance, and support.
Systems of systems are considered in this document to benefit from the same processes, methods and
tool capabilities as any system.
The relationships between this document and other standards are described in Annex E.
NOTE 1 This document prescribes a way to engineer systems and software based on models thanks to a
reference model and four process groups; however, other particular uses of models which are out of the scope
of this document are used in “model engineering” in other ways: For example, in model-driven modernization
[also called architecture-driven modernization (ADM) in object management group (OMG) terms], models are
(automatically) generated from the existing code and artefacts of a running system in order to represent it
and then build a new system in a different platform. Another usage scenario of models occurs in what is called
“models@runtime” whereby the models are used to change the system and evolve with it; these are normally
used in self-adaptive systems to achieve the required system self-adaptation features.
NOTE 2 The reference model does not take into account the system evolution (and that of its related models)
as a fundamental phase of systems or software engineering in the maintenance and evolution of the system and
its models.
NOTE 3 The design within the different domains, for example, mechanical, hydraulics, electrical, electronics,
control algorithms, and software, has been performed using model-based techniques for decades. However, each
domain uses specialized languages and tool chains for its modelling activities. The guideline to propose how
the methods, modelling languages and tools apply in these domains is outside of the scope of this document.
However, the interfaces of the engineering models and the system models are crucial and essential for applying
MBSSE.
In this document, the following verbal forms are used:
— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission;
viii
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
INTERNATIONAL STANDARD ISO/IEC/IEEE 24641:2023(E)
Systems and Software engineering — Methods and tools
for model-based systems and software engineering
1 Scope
This document deals with the tool capabilities and methods for model-based systems and software
engineering (MBSSE). This document:
— specifies a reference model for the overall structure and processes of MBSSE-specific processes,
and describes how the components of the reference model fit together;
— specifies interrelationships between the components of the reference model;
— specifies MBSSE-specific processes for model-based systems and software engineering; the
processes are described in terms of purpose, inputs, outcomes and tasks;
— specifies methods to support the defined tasks of each process;
— specifies tool capabilities to automate or semi-automate tasks or methods.
This document does not bring any additional life cycle processes for system and software but specifies
an MBSSE reference model considered as activities, not only from the life cycle perspectives of
systems engineering problem solving and the system-of-interest evolution, but also from the cognitive
perspectives of modelling and model management, which can sustain and facilitate the system and
software life cycle processes during digital transformation and in the digital age.
The processes defined in this document are applicable for a single project, as well as for an organization
performing multiple projects or an enterprise. These processes are applicable for managing and
performing the systems and software engineering activities based on models within any stage in the
life cycle of a system-of-interest.
2 Normative references
There are no normative references in this document.
3 Terms, definitions, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC, and IEEE 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 http:// www .electropedia .org
— IEEE Standards Dictionary Online: available at http:// dictionary .ieee .org
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and Software
Engineering Vocabulary) database and is publicly accessible at computer .org/ sevocab.
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
3.1.1
analytical model
model (3.1.15) that describes mathematical relationships, such as differential equations that support
quantifiable analysis about the system (3.1.35) parameters
Note 1 to entry: Analytical models can be further classified into dynamic and static models (3.1.34).
3.1.2
asset
item, thing, or entity that has potential, or actual value to an organization
Note 1 to entry: Assets can be classified from different perspectives, such as tangible assets, intangible assets;
moveable assets, immoveable assets. Intangible assets can be classified into digital assets and non-digital
intangible assets.
Note 2 to entry: Cognitive assets refer to intangible assets generated by an organization in the course of its
operations. Data, information, knowledge, wisdom, and modelling assets are all belong to cognitive assets.
[SOURCE: ISO/IEC 19770-1:2017, 3.1, modified — The original three notes to entry have been replaced
by two new notes to entry.]
3.1.3
capability
ability to do something useful under a particular set of conditions
Note 1 to entry: Generally, different kinds of capabilities exist: organizational capability, system (3.1.35)
capability, and operational capability. Organizational capabilities relate through the work practices that are
adopted by the organizations. New systems (with new or enhanced system capabilities) are developed to enhance
enterprise operational capability in response to stakeholders' (3.1.32) concerns (3.1.5) about a problem situation.
Operational capabilities provide operational services that are enabled by system capabilities. These system
capabilities are inherent in the system that is conceived, developed, created, and/or operated by an enterprise.
Enterprise SE concentrates its efforts on maximizing operational value for various stakeholders, some of whom
can be interested in the improvement of some problem situation.
3.1.4
concept of operations
verbal and graphic statement, in broad outline, of an organization’s assumptions or intent in regard to
an operation or series of operations of new, modified, or existing organizational systems (3.1.35)
Note 1 to entry: The concept of operations frequently is embodied in long-range strategic plans and annual
operational plans. In the latter case, the concept of operations in the plan covers a series of connected operations
to be carried out simultaneously or in succession to achieve an organizational performance objective. See also
operational concept (3.1.24).
Note 2 to entry: The concept of operations provides the basis for bounding the operating space, system
capabilities, interfaces, and operating environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.9]
3.1.5
concern
matter of interest or importance to a stakeholder (3.1.32)
EXAMPLE Affordability, agility, availability, dependability, flexibility, maintainability, reliability (3.1.27),
resilience (3.1.28), usability and viability are examples of concerns. Survivability, depletion, degradation, loss,
obsolescence are examples of concerns. The PESTEL mnemonic is a reminder of possible areas of concern:
political, economic, social, technological, environmental, and legal.
[SOURCE: ISO/IEC/IEEE 42020:2019, 3.8]
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
3.1.6
descriptive model
model (3.1.15) that shows an interconnected set of model elements (3.1.19) which represent key system
(3.1.35) aspects including its structure, behaviour, parametric, and requirements
Note 1 to entry: Descriptive models are complementary to analysis and design models of a system.
3.1.7
discipline-specific model
representation of a system (3.1.35), or system elements from the perspective of a discipline addressing
domain-specific concerns (3.1.5) where the model elements (3.1.19) come from a specific discipline
3.1.8
maturity
degree to which a system (3.1.35), product, or component meets needs for reliability (3.1.27) under
normal operation
Note 1 to entry: The degree of maturity of a system, product or component can be associated with trust in, and
good knowledge of, the behaviour of the system.
Note 2 to entry: The system, product or component is considered immature if there are still flaws or missing
parts that prevent users from benefitting from the item. The item is considered mature if there are no flaws or
missing parts that prevent users from benefitting from the item.
[SOURCE: ISO/IEC 25010:2011, 4.2.5.1, modified — The original note to entry has been replaced by two
new notes to entry.]
3.1.9
maturity level
degree of achievement to which all goals have been attained
3.1.10
measure of effectiveness
MOE
operational measure of success that is closely related to the achievement of the operational objective
being evaluated in the intended operational environment under a specified set of conditions
[SOURCE: ISO/IEC/IEEE 24748-4:2016, 4.7]
3.1.11
measure of performance
MOP
engineering parameter that provides critical performance requirements to satisfy a measure of
effectiveness (MOE) (3.1.10)
Note 1 to entry: An MOP typically characterizes physical or functional attributes relating to the system (3.1.35)
operation.
[SOURCE: ISO/IEC/IEEE 24748-4:2016, 4.8]
3.1.12
meta-model
special kind of model that specifies the abstract syntax of a modelling language
Note 1 to entry: The typical role of a meta-model is to define the semantics for how model elements (3.1.19) in a
model (3.1.15) get instantiated. A model typically contains model elements. These are created by instantiating
model elements from a meta-model (i.e. meta-model elements).
[SOURCE: ISO/IEC 19506:2012 Clause 4]
© ISO/IEC 2023 – All rights reserved
© IEEE 2023 – All rights reserved
3.1.13
mission
important operational job or duty assigned to a resource (3.1.29) or a group of resources or certain
groups of people
Note 1 to entry: A resource can be a human resource or a technical resource including systems (3.1.35) and
products.
3.1.14
mode
definition of the expected behaviour of the system (3.1.35) (or of its actors, or of its components) in
situations foreseen at design time
Note 1 to entry: Each mode is mainly characterized by the expected functional content of the system in this
mode. A mode can reflect various concepts, such as:
— phases (3.1.25) of a mission (3.1.13) or of a flight for example (taxiing, taking-off, cruising, landing, etc.);
— specific required functioning of the system under certain conditions (connected, autonomous, etc.);
— specific conditions where the system is used; test, training, maintenance, etc.
The transition from one mode to another is in general the result of a decision, such as a change in the way the
system operates, in order to adapt to new needs, or new contexts; it
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...