Next Article in Journal
Design of a Laser Driver and Its Application in Gas Sensing
Next Article in Special Issue
Vision-Based Autonomous Vehicle Systems Based on Deep Learning: A Systematic Literature Review
Previous Article in Journal
Detecting Deceptive Utterances Using Deep Pre-Trained Neural Networks
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Category Theory Framework for System Engineering and Safety Assessment Model Synchronization Methodologies

1
IRT SystemX, 8 Avenue de la Vauve, 91120 Palaiseau, France
2
Laboratoire Quartz—ISAE Supméca, 3 Rue Fernand Hainaut, 93400 Saint-Ouen, France
*
Author to whom correspondence should be addressed.
Appl. Sci. 2022, 12(12), 5880; https://doi.org/10.3390/app12125880
Submission received: 29 April 2022 / Revised: 4 June 2022 / Accepted: 6 June 2022 / Published: 9 June 2022
(This article belongs to the Special Issue Autonomous Intelligent Systems and Their Safety)

Abstract

:
In recent decades, there has been a significant increase in systems’ complexity, leading to a rise in the need for more and more models. Models created with different intents are written using different formalisms and give diverse system representations. This work focuses on the system engineering domain and its models. It is crucial to assert a critical system’s compliance with its requirements. Thus, multiple models dedicated to these assertions are designed, such as safety or multi-physics models. As those models are independent of the architecture model, we need to provide means to assert and maintain consistency between them if we want the analyses to be relevant. The model synchronization methodologies give means to work on the consistency between the models through steps of abstraction to a common formalism, comparison, and concretization of the comparison results in the original models. This paper proposes a mathematical framework that allows for a formal definition of such a consistency relation and a mathematical description of the models. We use the context of category theory, as this is a mathematical theory providing great tools for taking into account different abstraction levels and composition of relations. Finally, we show how this mathematical framework can be applied to a specific synchronization methodology with a realistic study case.

1. Introduction

During recent decades, systems have become more complex as they evolved towards having multiple features and due to the rise of mechatronic design. This complexity leads to a need to create numerous models in system design. We use these models to represent the product towards diverse modeling intents, thus allowing the analysis of specific properties.
Among these models, we find system engineering models used to apprehend complexity in the system. System engineering encompasses many models, including requirement and architecture models, safety models, and multi-physics models. These models are written by different people, using various tools and formalisms. This independence can lead to problems with consistency between the models. As diverse models represent one system, we fear that some models may contain errors, making them incompatible with the designed system. Such inconsistencies can be very concerning in the case of safety-critical systems and their safety models, and manual review of the models is time expensive. This is especially true of complex systems that can interact with humans, such as autonomous vehicles or cobots. Autonomous systems are complex and critical systems with highly complex control loops [1] that require advanced models when engineers simulate them. An undetected error in the safety model could lead to not considering some of the system’s potential failure events. Such errors would then result in the system being dangerous for the user. When systems have to be certified in order to be accepted into the market, e.g., for planes, the safety assessment methodology needs to be accepted by safety authorities. This requires great trust in the safety assessment process and, therefore, in the consistency of the models.
The system engineering community proposes different methodologies such as model federation [2] or proof theory approach [3] to assert and maintain consistency between these models to face this challenge. Amongst them, we find synchronization methodologies [4]. In this work, we address the mathematical aspect of the synchronization methodologies. The synchronization methodologies consist of three steps: first, we translate the models to a common formalism; then, we compare them in this common formalism; and finally, we carry the comparison results back to the original models.
Although those methodologies exist and provide means to minimize the number of contradictions between the models, there is no formal definition of what consistency the community would widely accept. We primarily understand consistency by the absence of contradiction between the models, but this is not a criterion that single-handedly allows a methodology’s efficiency to be demonstrated. Thus, we propose a formal definition of a binary consistency relation.
In this work, we propose to use category theory to interpret the model synchronization through a mathematical framework. We aim to provide a tool that helps design and validate model synchronization methodologies mathematically. To achieve this goal, we give a mathematical representation of the comparison models that the synchronization methodologies use, and we propose a definition of a general consistency relation between models. We apply this mathematical framework to the SmartSync methodology [5] through the study of model consistency in the design workflow of an autonomous critical system, a fixed-wing blood delivery drone. In the SmartSync methodology, the comparison models are mathematically depicted through quintuples that contain their characteristics. The mathematical framework described in this work proposes an equivalent definition of the comparison models, representing the models through categories rather than quintuples. This new definition allows our mathematical framework to give a new mathematical perspective of the comparison, which allows for mathematical proofs of the properties compared between the models. In the study case, through the categorical framework, we detect some limitations of the SmartSync methodology and propose some leads to overcome them.
The remainder of this paper is structured as follows:
Section 2 establishes the state of the art for the models, synchronization methodologies, and category theory tools that we use in this work. Section 3 defines the mathematical framework we propose for synchronization methodologies. Section 4 gives an example of applying the mathematical framework with the SmartSync methodology over a study case. Section 5 discusses some points of interest and the results of this study.

2. State of the Art

2.1. Model-Based System Engineering and Safety Assessment

During system design, engineers create representations that they use for different intents. We study the consistency of system engineering and safety assessment representation in this work, especially model-based ones. System engineering is an interdisciplinary approach for designing and integrating complex systems throughout their life cycle, from their design to their end of life. It is achieved by representing the system’s requirements, environment, life-cycle, functions, and architecture. Safety assessment aims at asserting that the system complies with its safety requirements. Whereas traditional approaches have been document-centered, industrial practices shift towards model-based approaches. Model-based approaches provide new tools that better consider complexity in system design. This change in modeling paradigm induces new engineering disciplines.

2.1.1. Model-Based System Engineering (MBSE)

The usual approaches for system engineering have been using documents to describe the requirements, environment, architecture, and other views of the system. Although those documents are sometimes created in tools such as Excel or Doors, they are textual and rely on natural language.
The model-based approach used in system engineering finds its origin in model-based software development [6]. Software developers use such approaches to represent software architecture, with tools such as the UML notation [7]. This language was derived into the SysML notation [8], which system engineers use to describe complex systems.
The model-based system engineering tools such as SysML or Capella use diagrams to represent different system views. Structural and behavioral aspects are represented, with diagrams such as requirement diagrams allowing for representation of the requirements, activities diagrams allowing for representation of the functions, and block definition and internal block diagrams allowing for representation of the architecture. The MBSE languages present a lack of semantics [9], which causes ambiguities without the use of a third-party methodology. Therefore architecture grids—such as CESAM [10] or the methodology from [11] for SysML or Arcadia for the Capella tool—provide guidelines to create MBSE models.
Although we often use the name MBSE for such diagrammatic models, system engineering encompasses various disciplines. Therefore, some domain-specific languages (DSL), such as languages for multi-physics or safety assessment, can be interpreted as part of MBSE.

2.1.2. Model-Based Safety Assessment (MBSA)

Similarily to MBSE, the field of safety analysis is faced with the challenge of complexity. The traditional approaches, such as Petri nets, reliability block diagrams, event trees, and fault trees, are models that are very close to mathematical equations and lack structure or lack expressivity power. They also are very abstract compared to the system specification. The model-based safety assessment (MBSA) approaches try to answer these limitations.
The MBSA models have a high expressivity, as they represent systems with a point of view closer to their architecture. The gain on expressive power is obtained by going from Boolean formalisms to state or event formalisms. There are three different kinds of model-based risk and safety assessment formalisms [12], including specialized profiles of MBSE tools such as [13], approaches that extend fault trees or reliability block diagrams such as dynamic fault trees [14] and model-based safety and reliability assessment modeling languages. In this work, we are interested in MBSA modeling languages, such as SAML [15], Figaro [16], and especially AltaRica 3.0 [17].
AltaRica 3.0 is the third version of the AltaRica language; it is based on the mathematical framework of guarded transition systems (GTS) [18], which are state automata.

2.1.3. Structural Models

The MBSE and MBSA models are two different kinds of models that represent the same systems with two different modeling intents. The modeling intent is the primary constraint on the representation of the system in these models.
In [19], the authors state that models are composed of behavior and structure. This means that these models are composed of a mathematical framework and a structural construction. In this work, we are interested in comparing the structure of the models, as we want to show that the architectures of the systems represented by the models are the same.
The article also introduces S2ML (System Structure Modeling Language), a language designed to model systems structure. This language is built around basic elements: blocks, ports, and connections. These three basic concepts, although very restricted, allow for a robust conceptualization of systems. Many languages can be interpreted through them, such as SysML, AltaRica, Modelica, and Lustre.

2.2. Synchronisation Methodologies

Different approaches exist to assert consistency between heterogeneous models. The model federation [2] approach uses a database to store all data from a system’s models. Within that database, the user can assert consistency and traceability between the models. Proof theory is used by [3] in their inconsistency management approach. This methodology interprets models as first-order logics, identifying inconsistencies through a computer-aided proof tool. The lack of expressivity of proof theory limits this approach, making the interpretation and proofs difficult.
A third approach to heterogeneous models consistency is model synchronisation [4]. The synchronization consists of a three-step process, which is illustrated in Figure 1:
  • Abstraction: The models are translated to a common formalism.
  • Comparison: The comparison is operated in the abstracted models. Writing the compared models in a common formalism makes the comparison easier than with heterogeneous models.
  • Concretization: The comparison results are carried back to the original models. Concretization can be achieved by correcting the models, annotations, or other means.
The model synchronization approach is the base for different methodologies. In this work, we intend to interpret them in a mathematical framework.
Regarding the SmartSync synchronization framework [20], the authors of the methodology provide a methodology and tools for the synchronization of the MBSE and MBSA models [21]. The comparison is operated on abstracted models written with the S2ML language [22]. The S2ML comparison models used in SmartSync are described with a set-theoretical point of view as a quintuple < P , C , B , α , r [5], where:
  • P and B are sets of symbols called ports and blocks, respectively;
  • C is a multiset of subsets of P called connections;
  • α is a subset of B × ( P C B ) such as any element of ( P C B ) that is associated with, at most, a unique element of B called its parent, and there exists a unique block r B with no parent.
SmartSync relies on the user to manually align model elements, as described in Section 4.2.1.
The directed graph methodology from [23] is also a synchronization methodology. It does rely on the abstraction of the models towards graphs. In the graphs, vertices represent parts and ports from SysML and blocks and classes from AltaRica; edges represent connectors from SysML and assertions from AltaRica. This framework allows for the use of graph search algorithms to traverse the graphs, and the use of concepts such as graph and sub-graph isomorphisms to compare the models.
The consistency links methodology [24] is another synchronization approach that creates links between MBSE and MBSA models. This methodology mainly focuses on the functional aspect of the system.
The three latest methodologies provide a structural comparison between system engineering and safety models. They rely on comparison models that follow the block, ports, and connection structure described in Section 2.1.3, with different ways to represent them. Category theory offers a point of view that allows us to use both the strengths of the graph and set theories, along with other topological tools, which is why we use it to provide a mathematical framework for synchronization methodologies. We do not find a clear formalisation of the consistency notion that seems to be widely accepted by the community. We provide a mathematical framework within which we define an axiomatic for the representation of models and propose a formal definition of a consistency relation.

2.3. Category Theory

Category theory is a branch of mathematics that finds its origins in the work of Samuel Eilenberg and Saunders Mac Lane in the early 1940s. This theory aims at unifying mathematics, especially by creating a bridge between topology and algebra. After category theory was used for many years to redefine existing concepts, Alexander Grothendieck did build completely new mathematical objects using it [25]. In this work, we use category theory to allow us to describe objects through their interactions. We detail in this section some basic knowledge of category theory that is required to understand this paper. A more complete yet well-written and easily understandable introduction to category theory can be found in [26].

2.3.1. Category

Category theory studies categories, which are mathematical entities that contain objects and relations between objects.
In this context, mathematicians use relations to study the properties of objects rather than looking at the objects themselves. It is also possible to define relations between categories called functors; this leads to defining more extensive categories within which the objects are the categories and the relations are the functors. Although this can sound complicated when first encountered, it provides a way to represent abstraction levels; this concept also leads to the definition of some fundamental concepts for logic that we do not use here.
We choose to use category theory in this work because of its properties that encompass both set theory and graphs. At the same time, category theory also has essential composition properties that allow propagating relations in the models we study and abstraction properties that are interesting in model comparisons.
Definition 1.
Category
A category C is composed of:
  • A class Ob(C) of objects;
  • For x , y O b ( C ) , the set H o m C ( x , y ) of morphisms from x to y;
          
    Morphisms are often called arrows;
          
    This set is called the Homset of x and y.
A category respects the following rules:
  • Composition: If f H o m C ( x , y ) and g H o m C ( y , z ) , then g f H o m C ( x , z ) .
  • Associativity: If f,g,h are morphisms such that g f and h g exist, then ( h g ) f = h ( g f ) .
  • Identity: for each x O b ( C ) , there exists an identity morphism I d x : x . x
We can give a graphic representation of a category through an oriented graph. This representation is called a diagram over the category. Vertices represent the objects of the category, and edges represent the morphisms. A diagram does not have to be exhaustive over the category. Thus, we can draw a finite diagram over a category with an infinity of objects (such as the S 2 M L + C a t category that we define in Section 3). We often do not show identities and morphisms resulting from diagrams’ composition, which allows better readability.
Just like other mathematical objects, we can link categories through applications. The right concept of application between categories is functors, a categorical pendant of morphisms.
Definition 2.
Functor
For two categories C, D, a functor F is an application F : C D composed of:
  • A function F O b : O b ( C ) O b ( D ) ;
  • For each x , y O b ( C ) , a function F x , y : H o m C ( x , y ) H o m D ( F O b ( x ) , F O b ( y ) ) .
We can note F(x) or F(f) if x is an object and f a morphism.
A functor F : C D satisfies the following requirements:
  • Identities are preserved by F, i.e., for x O b ( C ) , F ( I d x ) = I d F ( x ) ;
  • Composition is preserved by F, i.e., for x , y , z O b ( C ) and f H o m C ( x , y ) , g H o m C ( y , z ) , we have F ( g f ) = F ( g ) F ( f ) .
There exist applications between functors called natural transformations. Natural transformations are mappings for each object and morphism of a category between the images of their images by two functors. In this aspect, they allow transforming a functor into another functor. They are essential in defining the equivalences of categories.
Definition 3.
Natural transformation
Let C and D be two categories.
Let F : C D and G : C D be two functors.
A natural transformation α : F G is composed for each x O b ( C ) a morphism α x : F ( x ) G ( x ) such that for each y O b ( C ) , for each f H o m C ( x , y ) , we have:
G ( f ) α x = α y F ( f )
This corresponds to saying that the diagram found in Figure 2 commutes.

2.3.2. Some Interesting Concepts

We have defined the basic concepts of category theory; we will now focus on some properties of interest to this work.
In the same way as functions can be injective, surjective, or both (bijective), there are similar concepts for functors between categories.
Definition 4.
Full and Faithful functors
Let F : C D be a functor.
We say that F is Full if for any x , y O b ( C ) , F x , y : H o m C ( x , y ) H o m D ( F ( x ) , F ( y ) ) is a surjection. We say that F is Faithful if for any x , y O b ( C ) , F x , y : H o m C ( x , y ) H o m D ( F ( x ) , F ( y ) ) is an injection.
We can also define the concept of equivalence between two categories.
Definition 5.
Equivalence of categories
Let C and D be categories.
An equivalence of categories is a functor F : C D such that there exists:
  • A functor G : D C ;
  • Natural transformations α : I d C G F and α : I d D F G .
The notion of pullback allows defining an object that is the biggest object that respects a constraint towards two objects. Prerequisites for this notion are cones and limits, so we shall define them first.
Definition 6.
Cone
Let C be a category. Let there be a diagram over C. A cone over this diagram is an object Z with morphisms from Z to every object of the diagram, such that any newly formed triangle commutes.
A limit is a universal cone, i.e., a cone such that, for any other cone, a unique path exists from the limit to the other objects in the diagram through the cone.
Definition 7.
Limit
Let C be a category. Consider a diagram over C. A limit on this diagram is a cone Q such that for any other cone Z we have a unique morphism ψ : Z Q such that all triangles including ψ commute.
Cones and limits are illustrated in Figure 3. The diagram considered is constituted of the A, B, C, and D objects and morphisms between them. Z and Q, assuming that compositions of morphisms of the diagram with the dotted arrows commute, are cones. Furthermore, Q is a limit of the diagram if for any cone Z, there is a unique morphism Ψ : Q Z that makes everything commute. We say that a limit is a universal cone because whichever cone we choose, there is a unique way to obtain this cone from the limit, and this way is the ψ morphism.
Definition 8.
Pullback
Let A, B, and C be three objects of a category. Let f and g be two morphisms from A and B to C. A pullback in a category is the limit A x C B of the diagram from Figure 4.
The pullback is an object with morphisms towards two objects that respects constraints with a third object. This can be interpreted as the biggest object that respects the constraint.

2.3.3. Use of Category Theory in System Engineering

Because category theory is a tool that encompasses abstraction levels and interactions between objects, some approaches have given representation of complex systems through this mathematical frame.
Fundamental mathematical approaches give highly theoretical representations of these systems. Dynamic systems can be represented using the concept of sheaves [27], which are functors from a category to the category of sets with compelling topological properties. This allows for the representation of interactions between multiple dynamic systems. Category theory can also be used to represent systems in a way that allows for straightforward representation of hierarchy levels with evolutive memory systems [28], through the evolution of the system, and interactions between multiple systems.
Some approaches are closer to the system engineering point of view. Ontologies and category theory are used to represent MBSE models in the MB2SE framework [29]. A category-based meta-model of system engineering and safety assessment was also designed [30].

3. Mathematical Framework for Consistency

3.1. Mathematical Representation of a Structural Model

In this section, we assume that a model that carries structural information can be described with the following elements:
  • Blocks;
  • Ports;
  • Connections.
This is at least the case with the comparison formalisms used in the synchronization methodologies from Section 2.2, although they are named differently in the consistency links methodology. In [5], the S2ML models are formalized with a quintuple composed of sets of ports and blocks, a multiset of connections, a composition relation, and a unique block with no parents regarding the relation.
Although this description is rigorous, we propose another definition inspired by category theory which allows for the definition of functors between the models. To give a categorical definition of S2ML models, we need to define four concepts: ports, connections, blocks, and then S2ML models.
Definition 9.
Port
A port is a singleton containing a symbol p.
The ports are atomic elements of the model. They can be used to express variables in the model, states of a component, or other properties. We use symbols to represent this property; the symbol could be interpreted as the port’s name.
Definition 10.
Connection
A connection is a non-empty, finite set of ports.
This definition means that a connection is a category that contains the ports that it connects.
We can now define the blocks with ports and connections, which are containers in the model. A block is a container that holds other blocks, ports, and connections. Therefore the definition of a block is recursive.
Definition 11.
Block
A block is a category B such that:
  • O b ( B ) is a finite set of blocks, ports and connections;
  • For each connection C, if a port P O b ( B ) is such that P O b ( C ) , then there exists two functors r P , C : P C and r P , C : C P in B such that r P , C maps p P to P O b ( C ) and r P , C maps every element of C to p O b ( P ) and every morphism to I d p .
  • For each block B 1 O b ( B ) :
    -
    For each connection C O b ( B 1 ) , we have C O b ( B ) and there is a morphism α C , B 1 : C B 1 in B that maps each element of C to C O b ( B 1 ) ;
    -
    For each port P O b ( B 1 ) , we have P O b ( B ) and there is a morphism α P , B 1 : P B 1 in B that maps p P to P O b ( B 1 ) ;
    -
    For each block B 2 O b ( B 1 ) , we have B 2 O b ( B ) and there is a morphism α B 2 , B 1 : B 2 B 1 that maps every object of B 2 to itself in B 1 and does the same with morphisms;
    For each X in O b ( B 1 ) , there exist a unique block B B (possibly B 1 ), such that there is no block B B such that X B ; we also have either B = B 1 or B O b ( B 1 ) ;
  • There are no other morphisms in the block than those described here and the morphisms that derive from category theory axioms, i.e., identities and compositions.
Although this definition can look very complicated, it simply carries the properties of a block to the world of categories. Thus, each point of the definition can be explained straightforwardly.
We define two morphisms between a connection and the ports that are in the block and the connection. These morphisms represent the relation between the ports and the connection. The ports are both parts of the connection, and the connection refers to them. The typical structure of a connection in a block is depicted in Figure 5; it corresponds to the connection from Figure 6. We do not assume that all ports of the connection are contained in the block. In a model, we will eventually find an ancestor block containing all the connection’s ports. However, connections usually go from one block to another. Thus, there is no reason for all ports to be contained in any block that contains the connection.
In Figure 5, the plain arrows represent the r P 1 , C , r P 1 , C , r P 2 , C and r P 2 , C morphisms, and the dotted arrows represent their compositions. We have morphisms both from the ports to the connection and from the connection to the ports. Therefore, we also have morphisms between ports that participate in the same connection because of composition. In the same way, assume we have three ports, P1, P2, and P3, and two connections, C1 between P1 and P2 and C2 between P2 and P3. We will have morphisms between P1 and P3 because of composition, indicating an indirect connection between these ports.
The third point of the definition does translate the belonging relation in S2ML models. We define a morphism between a block, port, or connection and a block that contains it. In the case of blocks, this morphism resembles the identity; it maps every object of the port to its parent or ancestor. This means that everything in the block is also contained in its ancestors. For connections, this relation will absorb the content of the connection to itself since the connection conceptually only refers to the ports rather than being a container that they are a part of. This also helps to disambiguate the difference between a port being in a connection that belongs to a different block and a direct belonging morphism from a port to a block. The last property of that point expresses that a model element has a unique parent, either the block itself or a block within it. All other blocks that contain it are its ancestors and will contain this parent.
An example of the category depicting the system block from Figure 6 is depicted in Figure 7. This category indeed contains everything that is contained in the system block. In this case, this includes the A and B blocks, the P1 and P2 ports, and the C connection.
We have defined all elements of the models: blocks, ports, and connections; we can now use these concepts to define the model itself. The model contains the blocks, ports, and connections and is structured as its root (main) block, with the difference that it also contains the root block and morphisms between elements of the root block and the root block.
Definition 12.
S2ML Model
An S2ML model is a category M such that:
  • Ob(M) is a finite set of blocks, ports, and connections;
  • There exists a block R called the root of M such that O b ( R ) = O b ( M ) \ R , and for each x , y O b ( R ) , H o m M ( x , y ) = H o m R ( x , y ) ;
  • The morphisms described between each object and a block in the definition of a block also hold between the objects of M and the block R;
  • There are no other morphisms in the model than those described here and the morphisms derived from category theory axioms, i.e., identities and compositions.
The root object in the model does contain all other objects; there will always be a belonging morphism from an object to the root object.
We can draw diagrams over S2ML models like diagrams are drawn over any other categories. In order to make these diagrams easy to read and faithful to the system, we only show the direct belonging morphisms and morphisms between ports and connections. Any morphism that is a composition or identity still exists in the category, but we do not show them in the diagrams.
We have defined morphisms between the objects of the models. Although these morphisms can always be composed, they, in a way, are typed, as their properties can be used to explain the relationship they express between the objects. The belonging morphisms express that an object is contained in a block.
Definition 13.
Belonging Morphism, Direct Belonging Morphism, Ancestor, Parent
Let M be a model, let A , B O b ( M ) , and let f : A B a morphism in M.
We call f a belonging morphism if and only if B is a block, and:
  • A is a block, and f is the identity over this block;
  • A is a port, and f maps p A to A O b ( B ) ;
  • A is a connection, and f maps any x A to A O b ( B ) .
If f is a belonging morphism, we say that B is an ancestor of A.
We call f a direct belonging morphism if it is a belonging morphism and there is no block B O b ( B ) such that A O b ( B ) .
If f is a direct belonging morphism, we say that B is the parent of A.
We call a morphism a belonging morphism if its target is a block, and it either is similar to the identity when its source is a block or a port, or it maps everything to the connection itself if the source is a connection. Examples of direct belonging morphisms in the diagram for a model can be found in Figure 8; the plain black arrows are the direct belongings. Paths in the model formed by the composition of one or more direct belonging morphisms are the belonging morphisms; they correspond to the relations between a model element and its ancestors.
The other significant kind of morphism is reference morphisms. The reference morphisms show the relation between a port and a connection that the port participates in.
Definition 14.
Reference morphism
Let M be a model, let P , C O b ( M ) such that P is a port and C a connection, and let f : A B a morphism in M.
We call f a reference morphism if and only if f maps p P to P O b ( C ) .
Examples of reference morphisms can be found in Figure 8; they are the dotted arrows from P1 and P2 to C. The reference morphisms represent the encapsulation of the ports in the connections, as they are elements of the connection.
We call injections a certain kind of functors between models. These functors represent the fact that a model is part of another model.
Definition 15.
Injection
Let A, B be two S2ML models, and let F : A B be a functor. We call F an injection if and only if F is injective on objects and faithful, and F lets an object’s and morphism’s properties remain unchanged, i.e., ports, blocks, and connections are, respectively, mapped to ports, blocks, and connections, and reference and belonging morphisms are, respectively, mapped to reference and belonging morphisms.
A graphical illustration of injection between two models can be found in Figure 9. Injections are functors that associate each object and morphism of its source with a unique object or morphism of the target. The existence of an injection between two models means that the structure of the first model is a part of the structure of the second one.
Interesting properties of the objects can also be defined, which we use in the demonstrations of theorems.
The order of an object is the number of depth levels in the system breakdown separating this object from the root object of the model. We also call the order of the model the number of depth levels of system breakdown of the model.
Definition 16.
Order of a model object, order of a model
Let M be a model, and let X O b ( M ) .
We call the order of X its distance to the root object, i.e., the number of direct belonging morphisms that have to be composed to obtain a morphism, f : X R .
We call the order of M the upper bound of the orders of its objects.
The root of the model is an object of order zero, and objects with a direct belonging towards the root are of the first order. As an example, in Figure 8, the object of order zero is the block System, objects of the first order are the blocks A and B and the connection C, and objects of the second order are the ports P1 and P2. The model itself is of the second order since the ports have the maximal order.
We also define elementary blocks, which are blocks that do not contain other blocks. They are useful in inductive proofs, as they are the smaller blocks in the models, in the sense that they may be contained in other blocks that are subsequently “bigger” than them.
Definition 17.
Elementary block
We call an elementary block any block that contains no other block.
The S2ML models with the injections are a category that we call S 2 M L + C a t . S 2 M L + C a t is the frame within which we will study the characteristics of the models.
Definition 18.
S 2 M L + C a t
We define S 2 M L + C a t as being the category composed of:
  • O b ( S 2 M L + C a t ) , the set of all S2ML models. We call them the objects of S 2 M L + C a t ;
  • For each X , Y O b ( S 2 M L + C a t ) , Hom(X, Y) is the set of the injections from X to Y.
Proposition 1.
S2ML+Cat is a category.
Proof. 
  • Identity:
    Let X S 2 M L + C a t .
    The morphisms of S2ML+Cat are the injections between S2ML models.
    Due to the identity being trivially injective on objects and morphisms, it is an injection.
    Therefore, I d X H o m S 2 M L + C a t ( X , X ) .
  • Composition:
    Let X , Y , Z S 2 M L + C a t , let F H o m S 2 M L + C a t ( X , Y ) and let G H o m S 2 M L + C a t ( Y , Z ) .
    G F is an injection, because each of its components (over objects and homsets) is a composition of injective applications and thus an injective application.
    Therefore H = G F H o m S 2 M L + C a t ( X , Z ) .
  • Associativity:
    Injections are functors between categories; therefore, they are associative.
S2ML+Cat presents identity morphisms. Its morphisms can be composed, and their composition is associative. Therefore, S2ML + Cat is a category. □
We have defined a category that allows for the mathematical representation of S2ML models. Under the hypothesis that any structural model can be represented with blocks, ports, and connections, this mathematical representation is readily applicable to any such model. This is the basis for our mathematical framework.
The definition we have given here allows a unique categorical representation of any S2ML that was defined as a quintuplet.
Theorem 1.
Ob(S2ML + Cat) is isomorphic to the set of the quintuples from [5], up to the choice of symbols for blocks.
Proof. 
Let S2ML be the set of all quintuplets from [5].
Let F : S 2 M L O b ( S 2 M L + C a t ) X = < P , C , B , α , r > X c a t
where X c a t is such that:
  • Ob(X) contains:
    -
    For each p P , the port P = {p};
    -
    For each c = { P 1 , , P n } C , the connection c such as c = { P 1 , , P n } with P k = { P k } ;
    -
    For each block b B , the block b that contains all blocks, ports, and connections that are under b for the α relation;
  • The morphisms in X are trivially obtained from Definition 12.
The block b that we define is unique because it can be built by induction by building first the blocks that contain no blocks (the connection and ports being trivially unique, these blocks also are), then blocks of the next level of abstraction for the α relation, until we have built all blocks that are contained in  b .
F allows us to convert any model from S2ML to a model in O b ( S 2 M L + C a t ) .
Let G : O b ( S 2 M L + C a t ) S 2 M L X X q u i n t
where X q u i n t is the set of models < P , C , B , α , r > from S2ML, such that:
  • P = { p P C a t | P C a t O b ( X ) is a port };
  • B = { b′ | b′ is a symbol associated to b O b ( X ) , which is a block };
  • C = { c’ = { p P c a t for P c a t c | c O b ( X ) is a connection};
  • α = { ( x , y ) O b ( X ) 2 | H o m X ( x , y ) contains a direct belonging morphism };
  • r is the root of X.
The image of X q u i n t by F is X, by construction. Therefore, we have a way to map each element of S2ML to an element of O b ( S 2 M L + C a t ) . We also have a way to map each element of O b ( S 2 M L + C a t ) to a set of elements of S2ML. Finally, both these mappings are each-other inverse up to the choice of symbols for the blocks. □
A pleasing property is that when two models can be injected into one another, they have the same structure; this can be expressed as follows.
Theorem 2.
Let A , B O b ( S 2 M L + C a t ) , such that there exists injections F : A B and G : B A .
Then there exists an injection G : B A such that G F = I d A and F G = I d B .
Remark 1.
Theorem 2 is a generalisation of the Cantor-–Schröder-–Bernstein theorem to S2ML models.
Proof. 
Let M 1 , M 2 O b ( S 2 M L + C a t ) and F : M 1 M 2 , G : M 2 M 1 be two injections.
F and G are injective on objects; therefore, we know that c a r d ( O b ( M 1 ) ) = c a r d ( O b ( M 2 ) ) .
Let R be the root object of M 1 and R the root object of M 2 .
The belonging morphism between the object and its parent will also be mapped to a belonging morphism. Therefore, as F is injective, any object of M 1 which has a parent is mapped to an object of M 2 , which also has a parent.
Therefore all objects of M 2 that have a parent are the images of objects of M 1 that have a parent, since c a r d ( O b ( M 1 ) ) = c a r d ( O b ( M 2 ) ) .
Thus, since F is injective on objects, R = F ( R ) .
Let X O b ( M 1 ) be of order k.
By definition, there exists X 1 , , X k 1 O b ( M 1 ) and r 1 : X X 1 , …, r k : X k 1 R such that the r i are direct belonging morphisms.
Therefore, there exists X , , X k 1 = F ( X ) , , F ( X k 1 ) and r 1 : X X 1 , …, r k 1 : X k 1 R , where the r i are belonging morphisms, which are the images by F of the  r i .
This means that O r d e r ( X ) O r d e r ( X ) .
If we take the objects of maximum order in M 1 and M 2 , we obtain O r d e r ( M 1 ) O r d e r ( M 2 )  inversely.
Therefore, O r d e r ( M 1 ) = O r d e r ( M 2 ) .
Let k = O r d e r ( M 1 ) = O r d e r ( M 2 ) . Let n be the number of objects of order k in M 1 ; then, M 2 has at least n objects of order k, since O r d e r ( F ( X ) ) O r d e r ( X ) .
Since the same holds for G, we have that M 2 also has exactly n objects of order k.
Assume this property ( M 1 and M 2 have the same number of objects of a specific order and objects are mapped to objects of the same order) to be proven for any order above i [ | 0 ; k | ] .
Let X O b ( M 1 ) be an object of order i; then, O r d e r ( F ( X ) ) O r d e r ( X ) .
Any object of M 2 of an order superior to i is already the image of an object of M 1 of an order superior to i.
Therefore, O r d e r ( F ( X ) ) = O r d e r ( X ) = i .
We know that the property holds for objects of order k. For  i [ | 0 ; k | ] , if it holds for any order of [|i + 1,k|], it holds for order i; thus, by complete induction, it holds for any i [ | 0 ; k | ] .
Let C be a connection of M 1 .
Then c a r d ( F ( C ) ) c a r d ( C ) ; indeed, if  C = { P 1 , , P n } and F ( C ) = { P 1 , , P m } , then we have, for each i [ | 1 , n | ] a l such that F ( P i ) = P l , because F preserves the reference morphisms, thus m n .
This means that M 2 has more connections than M 1 for a certain order.
In the same way as for objects’ order, we obtain that the image of a connection by F and G is a connection with the same number of ports.
We can now prove the theorem. Let us show by complete induction that we can build an inverse of F.
Let n be the order of M 1 and M 2 .
For n = 0, M 1 and M 2 only contain their root objects, which are elementary blocks that have no port or connection.
Therefore, F and G are entirely defined by F(R) = R and G(R ) = R; they are trivially inverse of eachother.
Let n > 0, and assume that the property holds for any k < n.
Then:
  • F maps R to R and vice versa.
  • F maps each block B O b ( M 1 ) of order 1 to a block B O b ( M 2 ) of order 1. The component of F on B and its descendants corresponds to an injection F B between the models (of order < n) that have B and B′ as their root objects. Thus, we can associate an inverse G B to this injection.
  • M 1 and M 2 have the same numbers of ports of order 1 and connections of order 1.
    -
    Let C O b ( M 1 ) be a connection of order 1. We know that F(C) has the same number of ports as C and that the images of the ports of C are the ports of F(C). Therefore, we can define an inverse to the component of F on C, and its ports, and this inverse is compatible with the ones defined for blocks of order 1.
    -
    We can associate two by two the remaining ports. When we add the compositions to these components, we obtain a functor G : M 2 M 1 , which is the inverse of F.
Therefore, we have shown Theorem 2 by strong induction. □
A direct corollary of Theorem 2 is the following one.
Corollary 1.
Let A , B O b ( S 2 M L + C a t ) , such that there exists injections F : A B and G : B A .
Then, F is an equivalence of categories.
We can therefore give a simple definition of the equivalence of S2ML models.
Definition 19.
Equivalence of S2ML models
Let A , B S 2 M L + C a t .
We say that A and B are equivalent if there exists for F : A B and G : B A two injections.
Theorem 3.
The equivalence of S2ML models is an equivalence relation over Ob(S2ML+Cat).
Proof. 
We need to show that this relation is reflexive, symmetric, and transitive.
  • Reflexivity:
    Let A be a S2ML model.
    A is equivalent to A because the identity over A is an injection. Therefore, F = G = I d A and α composed of for each x, and  α x : F ( x ) G ( x ) with α = i d x suits.
  • Symmetry:
    A is equivalent to B, so the injections F : A B and G : B A exist. Therefore, we have two injections between B and A, and as such, B is equivalent to A.
    The relation is symmetric.
  • Transitivity:
    Let A, B, C be three S2ML, with A equivalent to B and B equivalent to C.
    Let F A , B and G B , A , be the equivalence injections for A, B and F B , C , G C , B be the equivalence injections for B, C.
    Then F : A C = F B , C F A , B and G : C A = G B , A G C , B are two injections between A and C. Therefore, A and C are equivalent.
 □
Another property of injection is that it, in a way, represents the fact that one model is bigger than another since it is a part of it.
Theorem 4.
The injection defines a partial order relation over the set of S2ML models, given equivalences between models.
Proof. 
  • Reflexivity :
    Let X be a S2ML model, and let I d x be the identity over X, i.e., the image of x O b ( X ) is x and for g H o m X ( x , y ) with x , y O b ( X ) the image of g is g. Then I d X is trivially an injection. Therefore, X is injected into X.
  • Antisymmetry:
    Assume X and Y are two S2ML models such that X is injected in Y and Y is injected in X, with  F : X Y and G : Y X such injections.
    Then, we have two injections between X and Y, and therefore, X and Y are equivalent.
  • Transitivity
    Let X, Y, and Z be S2ML models.
    Let F : X Y and G : Y Z be injections.
    Let H : X Z be the composition of F and G on objects and morphisms, i.e., composed of:
    H O b : O b ( X ) O b ( Z ) x G F ( x )
    and for each x , y O b ( X ) ,
    H x , y : H o m X ( x , y ) H o m Z ( H O b ( x ) , H O b ( y ) ) f G F O b ( x ) , F O b ( y ) F x , y ( x )
    Because each of the applications defined here are compositions of injective applications, they are injections. Therefore, H is an injection, and thus, X is injected in Y.
Therefore, the existence of these injections between S2ML models defines a partial order relation. □

3.2. Consistency Relation

Now that we have explained the category in which we are working, we can define a consistency relation between two S2ML models.
Definition 20.
Binary consistency relation
Let ∼ be a binary relation over O b ( S 2 M L + C a t ) . For  A , B O b ( S 2 M L + C a t ) , we note A B if ( A , B ) , i.e., if A is in relation with B.
∼ is a Binary consistency relation if and only if for A , B O b ( S 2 M L + C a t ) , there exist A′, B′ such that these injections exist:
  • f A : A A ;
  • f B : B B ;
  • F : A B ;
  • G : B A .
F and G respect the following properties:
  • F G = I d B ;
  • G F = I d A .
This definition means that the two models are in a consistency relation if the structure shown in Figure 10 exists with fa, fb, F, and G being injections. All the morphisms are injections and the compositions of F and G are the identities of A and B . Note that Theorem 2 implies that if this structure exists without the compositions of F and G being the identities, then we can find G such that F and G compose into the identities.
Such a relation is too general to describe a relevant interpretation of consistency between two models. To illustrate this idea, we can create a binary consistency relation such that any couple of models would be in the relation:
Proposition 2.
Let a l l be the binary relation over O b ( S 2 M L + C a t ) with no other restriction than being a binary consistency relation.
Let A , B O b ( S 2 M L + C a t ) .
Then A a l l B .
Proof. 
Let A , B S 2 M L + C a t .
We have A a l l B if there exists A′, B′ in O b ( S 2 M L + C a t ) such that there exist injections f A : A A , f B : B B , F : A B , and G : B A such that F G = I d B and G F = I d A .
Because A and B are S2ML models, there exists unique blocks r A O b ( A ) and r B B such as there are no morphisms in A (resp B) with domain r A (resp r B ).
Let A be the S2ML model with only one object r A and no morphisms and B be the S2ML model with only one object r B and no morphisms.
f A : A A r A r A is trivially an injection (we only present the injections through their mappings over O b ( X ) here since the models have no morphisms).
We define f B using the same construction.
Let F : A B r A r B and G : B A r B r A .
F and G are injections, and  F G = B B r B r B = I d B and similarly G F = I d A .
Therefore A a l l B . □
Our definition of a binary consistency relation describes the existence of a similarity between A and B. This similarity is the shared structure of A and B .
Because the definition is general, the fact that A and B are models induces a similarity: the existence of the main element of the model, namely r A and r B , unique elements of the models with no parents. This results in any couple of models being in relation.
This means that not all binary consistency relations are interesting for model comparison.
The main idea behind this definition is that we can complete it with restrictions to assert consistency over specific properties of the models. As an example, we define the dictionary consistency relation between two models:
Definition 21.
Dictionary consistency relation
We call adDictionary consistency relation a binary consistency relation d i c such that for A , B O b ( S 2 M L + C a t ) , A d i c B implies:
A′ and B′ are two models injected in A c o m p and B c o m p , where A c o m p and B c o m p are two models with the same sets of objects as A and B but no morphisms.
Such a relation consists of matching objects from one model to corresponding objects on the other model, except for some elements that are kept unmatched. Therefore, this method can be used to detect elements from one model that have no equivalent in the other model; they are the objects of A c o m p that are not in A (idem on the B side).
As before, it could be argued that any couple of models is in relation using this definition, as we could also take the models with only the main elements. For example, this could be solved by having a unique “name” attribute in our objects and considering that objects linked by the dictionary should carry the same name. However, that would be hiding the real problem since there is no guarantee that elements are named the same way in the original models. The reality is that such a dictionary would have to be created by the engineers, as the model elements carry a meaning that the computer cannot interpret. In general, the way to express a “good” consistency relation is to have a condition of maximality on the A and B models. One way to achieve this maximality is through the use of a pullback. We discuss these ideas in Section 5.1.
While defining the dictionary relation, we used the A c o m p and B c o m p models as an intermediary step between A / B and A / B . We use these models to eliminate the elements that we do not intend to compare in our binary consistency relation between A and B. In this way, the objects from A c o m p and B c o m p that are not in A′ and B′ will be the differences detected by the binary consistency relation.
Therefore, one possible structure to build a binary consistency relation over an existing synchronization methodology is the one found in Figure 11. S 2 M L + C a t could also be replaced by an equivalent construction over another common formalism.

4. Application Example with SmartSync

4.1. Study Case

The study uses a fixed-wing drone as its applicative example. This drone is inspired by the Zipline company blood delivery drone [31]. The specific use of this drone is the delivery of blood packages to different hospitals and clinics across a large area from a blood storage center. This drone is a fixed-wing drone, meaning a drone similar to a plane. Its powertrain has two coaxial motors, each linked to a propeller. The drone also presents redundancy in its ailerons, used to control direction. A control processing unit is placed in the removable battery of the drone and is given the flight plan before each flight. A QR code allows for identifying the blood package once installed in the drone cargo compartment until it is parachuted down to the delivery site. The drone takes off by being catapulted; then, it flies to the drop area. Cargo can be parachuted up to an 80 km radius, with a maximum time to objective of 45 min. The drone then comes back to the storage site. It lands by being caught by a recovery system, a sling between two 10-m high towers that attaches to a hook on the drone. An illustration of the drone’s external architecture and flight scenario can be found in Figure 12.
We consider a SysML architecture model as the specification of the system. From this architecture, we derived three models for different intents:
  • Safety assessment: An AltaRica 3.0 model represents the model for safety assessment.
  • Scenario: A SCOLA (SCenario Oriented LAnguage) model represents the functional scenarios.
  • Multi-physics: A Modelica model represents the multi-physics behavior of the drone’s power electronics and aerodynamics.
We asserted consistency over this design using SmartSync to synchronize these three models with the architecture model.

4.2. Applying SmartSync to the Study Case

This section applies the mathematical framework to a study case through the SmartSync approach. We show compatibility potential between SmartSync and our framework, but the mathematical definition of SmartSync within our framework is yet to come. This will be discussed in Section 5.

4.2.1. The Use of SmartSync

The SmartSync approach was operated through the following steps:
  • We translated the models to S2ML.
  • The SmartSync tool associated the main elements of both models and asked the user to align the children elements of the mains.
  • When given the associated children of the main, the SmartSync tool iterated the previous steps for these elements, asking the user to align their children.
  • Such iterations were done until the tool had entirely explored the models.
If an element has no equivalent in the other model, the user can give it the attribute forget if he can justify why it is not an inconsistency.
The SmartSync tool takes two S2ML compiled models (in the XML format) as an input and outputs a CSV comparison file. The user aligns the elements from both models in the CSV file, then re-iterates the SmartSync comparison with the two S2ML compiled models and the CSV file as an additional input. The SmartSync tool is then able to identify the children elements and provides a new CSV comparison file to the user for the next iteration.

Translation to S2ML

Before conducting each comparison, we first had to abstract the SysML model. The abstraction was made towards the S2ML language, which is used in the SmartSync methodology.
We translated the information from both the BDD and the IBD to conduce the abstraction. The S2ML model followed the hierarchy from the BDD and the structure of the IBD. We represented SysML “partProperties”, i.e., components of the system in the S2ML model, with blocks. We also used S2ML ports to represent SysML ports and S2ML connections to represent SysML connections.
An example of the transformation over part of the SysML model (namely the battery and drivetrain) is shown in Figure 13.
Once we translated the SysML model, we operated the comparison with the AltaRica model and the Modelica model. This was done by translating those models, then operating the SmartSync comparison.

MBSE/MBSA

To compare the SysML model and the AltaRica 3.0 model, we first translated the AltaRica 3.0 model to S2ML. This process was not complicated because the structural part of the AltaRica 3.0 languages is S2ML. Blocks were translated to blocks, variables to ports, and assertions to connections. An example of this translation can be found in Figure 14. In this example, it can be seen that some attributes giving more information on the AltaRica model were included in the S2ML model (e.g., “type = “Boolean””); these attributes are not currently used in the SmartSync comparison.
Once the translation was done, the models were given to the SmartSync tool as inputs. The tool then took an element of each model that it knew to correspond to one another. This was the main element of the models for the first step, i.e., the blocks representing the whole system. The tool then asked the user to align children of these two elements from both models. The user can align elements or give them the forget attribute—meaning the element is not supposed to have a counterpart in the other model—or do neither. The tool then iterated on each couple of aligned elements until all elements were either aligned or forgotten. When no element could be aligned anymore, the remaining elements with no counterpart were considered inconsistent.
In this case, the comparison between the architecture and AltaRica 3.0 models was done through 4 comparison steps. It shows that the MBSA model lacks some elements of the system. The missing elements are the redundant ailerons and the rudder airfoil. This is due to a communication issue when the safety model was designed based on an outdated version of the architecture model. Correction of these inconsistencies was conducted by adding the missing elements to the AltaRica 3.0 model.
Note that all safety artifacts were ignored in this comparison, such as state variables, events, etc. The comparison of the models also has shown that interactions with the environment such as gravity, 4G network, etc. have not been taken into consideration in the MBSA model. We deemed this normal in this work, but it could be argued that it should be added; therefore, consistency assessment would have resulted in adding these interactions to the MBSA model. Such decisions are non-trivial and should be undertaken by the system engineer and safety analyst; this is why the consistency assessment cannot be fully automatized. Of course, after modification of the model, a new comparison should be operated to assert that the correction did not introduce new inconsistencies.

MBSE/Multi-Physics

We needed to make a second comparison to assert the global consistency of our design with the Modelica/SysML comparison. The translation from Modelica to S2ML was done following the process described in [21], with the difference that we considered ModelicA′s variables. Part of this translation can be found in Figure 15 with the translation of the motor class. Modelica classes were abstracted to S2ML classes, with model instances being translated to blocks. Modelica variables were translated to S2ML ports, and connect clauses were translated to connections.
Once this translation was conducted, we compared the models with the SmartSync tool. A first iteration showed that the structure of the models is very different. For ease of comparison, we added drivetrain and cell blocks to the models, respectively containing the motors and propellers and the fuselage and wings. We then translated again and compared the models.
After four comparison steps, we had three conclusions:
  • Most components of the drone are missing in the Modelica model. This can be explained by the fact that we are here only interested in the propulsion and aerodynamics of the drone; therefore, components related to other functions are not represented.
  • In some specific cases, the Modelica representation is more detailed than the architecture model. This is the case of the motors since the SysML model only considers them through a black box view, whereas the Modelica view shows the inner parts of the motor for calculations.
  • There is an inconsistency between the models. This inconsistency is the presence of the fuselage within the Modelica model, which is modeled for aerodynamics purposes, but unrepresented in the architecture model. This inconsistency is corrected by adding the fuselage to the architecture model.

4.2.2. Categorical Point of View

In this subsection, we analyze the comparisons made in Section 4.2.1 in the context of the mathematical framework we defined in Section 3.

Visualisation of S2ML + Cat Models with NetworkX

In order to achieve this goal, we used oriented graphs that give a visual representation of the categorical S2ML models.
We created this representation at each step during the comparison to visualize which parts of the model the comparison traversed. Because SmartSync makes the comparison in a way that resembles a breadth-first search, this corresponds to taking the model with only its first level of abstraction (the main and its children) and then adding a level of abstraction for each iteration.
To obtain the graph representations, we wrote a python script that converts the CSV files created by the SmartSync tool to directed graphs over the underlying S2ML + Cat models. This script used the NetworkX package [32] as its basis for graph classes and visualization methods. This package is a library for the study of graphs and networks. It features classes for the representation of graphs and digraphs, and methods for graph analysis and visualisation.
The graphs we show here over the S2ML + Cat models only show direct belonging relations, blocks, and ports. The absence of composed morphisms is because we wanted to minimize the number of edges to allow for good readability. The absence of connections is related to the comparison made by SmartSync, which does not consider them yet.
For each iteration, the script also computed a correspondence matrix between objects of both models, which corresponds to giving the F and G functors from Figure 11. This matrix is represented as a table. Its element A n + 1 , m + 1 will contain −1 if the nth element of the first model or the mth element of the second has the attribute forget, 1 if they are aligned and 0 otherwise. The first column and line of the table, respectively, contain the first and second model elements’ names, meaning A n + 1 , 0 contains the name of the nth element of the first model, and  A 0 , m + 1 the name of the mth element of the second one, with the elements being arbitrarily numbered.
In this aspect, we can say that for each iteration, we have constructed the A C o m p and B C o m p S2ML + Cat models for the elements that were already aligned and the F and G functors. The A′ and B′ S2ML + Cat models are obtained by removing the objects with the attribute forget and the morphisms with these objects as the source or target.

Comparison with the S2ML + Cat Models

Figure 16 shows said graphs for the comparison of the SysML and AltaRica 3.0 models of the fixed-wing drone. Blocks are represented with green vertices and ports with blue ones, and diverse abstraction levels in the models are shown by different concentric ellipses of vertices.
Table 1 provides the correspondence matrix for the fixed-wing drone between the SysML and AltaRica 3.0 S2ML models. It can be observed that many ports are present in the SysML representation, whereas they are not in the AltaRica 3.0 model. This corresponds to the interfaces with the outside of the system that were discussed in Section 4.2.1.
From the final step of the comparison between the SysML and AltaRica 3.0 models, we can obtain the A′ and B′ S2ML + Cat models from Figure 11. These models are shown in Figure 17. We observe that although these graphs have different names for their vertices, they are the same graphs, meaning we indeed found a common skeleton between both models. This property characterizes the way we mathematically define a binary consistency relation.

5. Discussion

Although this mathematical framework does not provide a new synchronization methodology, it shows existing and future methodologies from a new point of view. In light of this new perspective, we have a new comprehension of some of the characteristics of these methodologies. We also show some current limitations and give ideas for improvement. This framework also allows us to formally show which exact characteristics of the models are compared through the synchronization methodology. In the case of SmartSync, we can tackle the topics of pragmatics, composition, and connections.

5.1. Pragmatics

In SmartSync, and more generally in the methodologies we presented in Section 2.2, the user is required to align the model elements manually. Although this seems like a bothersome and time-expensive step, we believe that it is almost impossible to do otherwise in general. Even though models have syntax and semantics that allow them to be interpreted by a computer, they also carry a meaning that only makes sense to humans. This meaning is called pragmatics. Pragmatic models, such as the MBSE models, carry a meaning that is lost if model elements are replaced with abstract names, such as described in [33]. The interested reader may find more information on pragmatics in the book [34].
The SmartSync tool deals with the semantic aspect of models by creating a form of a dictionary—the CSV file. In the general definition of consistency that we have given in this paper, we do not force the consistency relation to consider pragmatics. Yet, SmartSync still deals with pragmatics, so we should explain how that makes sense in the S2ML + Cat Framework.
One way to include pragmatics in the S2ML + Cat framework is the idea that we should build the biggest common skeleton to both models that respects the user’s dictionary. This can be achieved by constructing a model that represents the dictionary. Injections towards this model from both A c o m p and B c o m p and then building the pullback of A c o m p and B c o m p will allow representing the alignment of objects by the user. Therefore, as depicted in Figure 18, the A′ and B′ categories would be the pullback of A c o m p and B c o m p .
We need to precisely define the dictionary if we want to operate the computation of the pullback or even prove that it does always exist. An idea for that would be to build it from A c o m p and B c o m p with these constraints:
  • O b ( D i c t i o n a r y ) is a set of blocks, ports and connections, such that we have p : O b ( A c o m p ) O b ( D i c t i o n a r y ) , q : O b ( B c o m p ) O b ( D i c t i o n a r y ) such that for each x O b ( A c o m p ) and y O b ( B c o m p ) , we have p ( x ) = q ( x ) if and only if the elements have been aligned by the user;
  • p and q are injective functions;
  • We give the dictionary the form of a model by building the morphisms needed to have images of the morphisms of A c o m p and B c o m p when we enrich p and q to make them functors.
We can make it so that this category is unique by choosing the symbols for the ports judiciously, but it is not important, as any such category would suffice to represent that we aligned the objects of A c o m p and B c o m p .
Although we do not care for the category structure in the dictionary, we can build it. The components over the objects of the p and q functors carry important information, i.e., the alignment of model elements.

5.2. Composition

The aspect of composition in category theory is of high interest in the concepts that we define.
The morphisms in the categories of S2ML + Cat define relations between the model elements to allow us both to apprehend the direct and composed relations. In [5], the definition of S2ML does provide a composition relation that only links an element and its parent. In S2ML + Cat, however, the belonging morphisms define the Cartesian closure of this relation. This allows us to identify all the ancestors of an object very quickly.
Even though this is not yet taken into account in the methodology that we have tested with the study case, this means that the binary consistency relation that we define is able to encompass cases where a model element is at a certain level of abstraction in one model and another level of abstraction in the second model. A simple example of such a difference is if we represent a gear motor in the system. We can, in one model, have a gear motor block that contains a motor block and a gear block, and, in the other model, directly represent the motor and gear blocks without the gear motor level.
This would result in the categories shown in Figure 19. In these diagrams, we identify the direct belongings to the black arrows and their composition to the dotted arrows. We can easily understand that the dotted arrows in the first case correspond to the black ones in the second; therefore, these models can be deemed consistent with one another.
The second kind of relations that we have in the models are those between the ports and the connections they participate in. Because of the way we defined the morphisms between ports and connections, and thanks to composition, we obtain morphisms between ports that participate in the same connection, as shown in Figure 5.
We also obtain morphisms between ports that are indirectly connected, i.e., in the case where we have three ports, with two connections between two of them. Such a structure will lead to the existence of morphisms between the two ports that are not part of the same connections. This allows us to apprehend indirect connections between ports. Thus, we could consider the case in which one connection on one side corresponds to multiple ones on the other side.
An example of such a case is given in Figure 20. Some system engineers consider the representation on the left to be best practice: a connection should not cross the frontier of a block; therefore, there should be intermediary ports when crossing to a different abstraction level. In a model dedicated to computation, such as the MBSA models, doing this is a problem because it increases the amount of computation needed to execute the system. Thus, the representation on the left also makes sense to represent the system.
The categories for the two blocks diagrams from Figure 20 can be found in Figure 21. Thanks to the composition detailed above, we obtain the dotted arrows that can be aligned in the model comparison from the categorical point of view.

5.3. Connections

We discussed in Section 5.2 the fact that composition allows for better consideration of the connection. As SmartSync does not yet consider connections, we have not demonstrated this in the study case.
It is interesting to note that it should theoretically not be difficult to add support of connections. The ports are already aligned in SmartSync. We could consider the ports of a connection in model A and verify if their counterparts in model B are also connected.

5.4. Connections and Tuples

In Section 3.1, we defined the connections as sets of ports. Although this definition is consistent with the quintuplet definition of S2ML models from [5], the reader could argue that the order of ports in a connection can be significant, for an example, if there is a direction to the connection. This could be considered in the quintuplet definition by using tuples rather than sets to define the connections.
In the case of the categorical definition of S2ML models, we could consider this property by defining connections as categories, with ports being the objects of the category and morphisms from a port A to a port B if port A precedes port B in the connection.

5.5. Version Control

We believe this framework can help consider version control in the consistency assessment of the models. Indeed, when the models evolve, the vast majority of their architecture is generally left unchanged. Detecting which parts are unchanged and, thus, do not need to be reassessed for consistency could be a considerable gain in engineering time. The review process would only need to consider small sections of the models.
Consider the structure denoting a consistency relation as in the S2ML + Cat part of Figure 11 for each version number of the models. Say we compare MBSE model n with MBSA model n, and after modifications, we want to consider the consistency of MBSE model n + 1 with MBSA model n + 1. We can consider these structures as categories and then construct a functor from one to another that would provide correspondence between the unchanged elements. We hope to explore this idea in future work.

5.6. Perspective about Comparison of This Framework with Other Formal Definitions of Consistency Outside the Scope of MBSE/MBSA

We have not encountered a similar formalization of the concept of consistency between structural models. However, we believe that this work would significantly benefit from being compared with other theoretical frameworks intended to achieve similar goals. We intend in further work to define comparison criteria and operate a comparison through one or more examples. These criteria could include, but may not be limited to, the capacity to encompass:
  • Different kinds of inconsistencies;
  • Internal (i.e., consistency of a model within itself) and/or external consistency (i.e., consistency between different models);
  • Traceability between successive versions of the models;
  • Diagnostics of the inconsistencies;
  • Resolution of the inconsistencies.

6. Conclusions

This paper establishes a mathematical framework for consistency between structural models, especially system engineering and safety assessment models. In the context of synchronization methodologies, where heterogeneous models are translated to a common formalism for comparison, we give a categorical representation of the translated models. These categories are linked through injections, which are functors that specify that a category is conceptually contained in another. Using the models as objects and injections as morphisms, we define S2ML + Cat as the category of S2ML models.
In S2ML + Cat, we give a definition of what we call a consistency relation. This definition allows us to consider synchronization methodologies from a mathematical point of view.
We applied this framework to a study case through a fixed-wing drone. We show that we can mathematically interpret a synchronization methodology.
We argue that the use of category theory in this framework allows for the consideration of composition and abstraction levels in the models, and the study case results give clues for improvement in the synchronization methodology. These improvements would include considering the connections and the differences in abstraction level between the models.
Overall, this mathematical framework is not a new synchronization methodology but rather a new point of view on synchronization that allows for a better understanding of the methodologies. It also allows for mathematical proofs of the methodology’s effectiveness and better apprehend leads for improvements. In future work, we expect to demonstrate that SmartSync and its encompassing of pragmatics can be modeled through a pullback in S2ML + Cat. We also hope to propose improvements to the current methodology, using the leads we presented to deal with connections and system levels. Finally, we believe that we can improve this framework to consider successive versions of the models and transfer comparison results to unchanged parts of the models.

Author Contributions

Conceptualization, J.V.; methodology, J.V.; software, J.V.; validation, J.V., M.B., F.M. and J.-Y.C.; formal analysis, J.V.; investigation, J.V.; writing—original draft preparation, J.V.; writing—review and editing, M.B., F.M. and J.-Y.C.; visualization, J.V.; supervision, M.B., F.M. and J.-Y.C. All authors have read and agreed to the published version of the manuscript.

Funding

This work was funded by the S2C project at IRT SystemX and its partners.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

Data are available on request.

Acknowledgments

Part of the models for the study case were developed in collaboration with Imane Bouhali during her master thesis internship at ISAE Supmeca.

Conflicts of Interest

The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

Abbreviations

The following abbreviations are used in this manuscript:
MDPIMultidisciplinary Digital Publishing Institute
MBSEModel-Based System Engineering
MBSAModel-Based Safety Assessment
UMLUnified Modeling Language
SysMLSystem Modeling Language
DSLDomain-Specific Language
SAMLSecurity Assertion Markup Language
GTSGuarded Transition System
S2MLSystem Structure Modeling Language
SCOLASCenario Oriented LAnguage
CSVComma-Separated Values file format
BDDBlock Definition Diagram
IBDInternal Block Diagram

References

  1. Gul, F.; Mir, I.; Abualigah, L.; Sumari, P.; Forestiero, A. A Consolidated Review of Path Planning and Optimization Techniques: Technical Perspectives and Future Directions. Electronics 2021, 10, 2250. [Google Scholar] [CrossRef]
  2. Guychard, C.; Guerin, S.; Koudri, A.; Beugnard, A.; Dagnat, F. Conceptual interoperability through Models Federation. In Proceedings of the Semantic Information Federation Community Workshop, Miami, FL, USA, October 2013. [Google Scholar]
  3. Finkelstein, A.; Gabbay, D.; Hunter, A.; Kramer, J.; Nuseibeh, B. Inconsistency handling in multi-perspective specifications. IEEE Trans. Softw. Eng. 1994, 20, 569–578. [Google Scholar] [CrossRef] [Green Version]
  4. Legendre, A. Ingénierie Système et Sûreté de Fonctionnement: Méthodologie de Synchronisation des Modèles d’Architecture et d’Analyse de Risques. Ph.D. Thesis, Université Paris Saclay (COmUE), Gif-sur-Yvette, France, 2017. [Google Scholar]
  5. Batteux, M.; Prosvirnova, T.; Rauzy, A. Model synchronization: A formal framework for the management of heterogeneous models. In Proceedings of the International Symposium on Model Based Safety Assessment, IMBSA 2019, Thessaloniki, Greece, 16–18 October 2019. [Google Scholar] [CrossRef] [Green Version]
  6. Estefan, J. (NASA Jet Propulsion Laboratory, Pasadena, CA, USA). Personal communication, 2008. [Google Scholar]
  7. OMG. OMG Unified Modeling Language; Version 2.5.1; OMG: Needham, MA, USA, 2017. [Google Scholar]
  8. OMG. OMG Systems Modeling Language (OMG SysMLTM); OMG: Needham, MA, USA, 2018. [Google Scholar]
  9. Wach, P.; Salado, A. The need for semantic extension of SysML to model the problem space. In Proceedings of the Systems Engineering Research (CSER), Redondo Beach, CA, USA, 20–22 March 2020. [Google Scholar] [CrossRef]
  10. Krob, D. CESAM: CESAMES Systems Architecting Method—A Pocket Guide; ESAMES Association: Paris, France, 2017. [Google Scholar]
  11. Mhenni, F.; Choley, J.-Y.; Penas, O.; Plateaux, R.; Hammadi, M. A SysML-based methodology for mechatronic systems architectural design. Adv. Eng. Inform. 2014, 28, 218–231. [Google Scholar] [CrossRef]
  12. Batteux, M.; Prosvirnova, T.; Rauzy, A. AltaRica 3.0 in 10 Modeling Patterns. Int. J. Crit. Comput. Based Syst. (IJCCBS) 2017, 9, 133–165. [Google Scholar] [CrossRef]
  13. Mhenni, F.; Choley, J.-Y.; Nguyen, N.; Frazza, C. Flight Control System Modeling with SysML to Support Validation, Qualification and Certification. IFAC-PapersOnLine 2016, 49, 453–458. [Google Scholar] [CrossRef]
  14. Dugan, J.B.; Bavuso, S.J.; Boyd, M.A. Dynamic Fault-Tree Models for Fault-Tolerant Computer Systems. IEEE Trans. Reliab. 1992, 41, 363–377. [Google Scholar] [CrossRef] [Green Version]
  15. Gudemann, M.; Ortmeier, F. A framework for qualitative and quantitative model-based safety analysis. In Proceedings of the IEEE 12th High Assurance System Engineering Symposium (HASE 2010), San Jose, CA, USA, 3–4 November 2010; pp. 132–141. [Google Scholar] [CrossRef]
  16. Bouissou, M.; Bouhadana, H.; Bannelier, M.; Villatte, N. Knowledge modelling and reliability processing: Presentation of the FIGARO language and of associated tools. In Proceedings of the SAFECOMP’91—IFAC International Conference on Safety of Computer Control Systems, Trondheim, Norway, 30 October–1 November 1991; pp. 69–75. [Google Scholar] [CrossRef]
  17. Batteux, M.; Prosvirnova, T.; Rauzy, A. AltaRica 3.0 Language Specification. 126p. Available online: https://www.openaltarica.fr/docs/AltaRica3.0LanguageSpecification-v1.1.pdf (accessed on 27 April 2021).
  18. Rauzy, A. Guarded transition systems: A new states/events formalism for reliability studies. Proc. Inst. Mech. Eng. Part J. Risk Reliab. 2008, 222, 495–505. [Google Scholar] [CrossRef] [Green Version]
  19. Batteux, M.; Prosvirnova, T.; Rauzy, A. From Models of Structures to Structures of Models. In Proceedings of the 4th IEEE International Symposium on Systems Engineering, ISSE 2018, Rome, Italy, 1–3 October 2018. [Google Scholar] [CrossRef] [Green Version]
  20. Batteux, M.; Choley, J.-Y.; Mhenni, F.; Prosvirnova, T.; Rauzy, A. Synchronization of System Architecture and Safety Models: A Proof of Concept. In Proceedings of the International Symposium on Systems Engineering (ISSE), Edinburgh, UK, 1–3 October 2019; pp. 1–8. [Google Scholar] [CrossRef] [Green Version]
  21. Batteux, M.; Choley, J.-Y.; Mhenni, F.; Palladino, L.; Prosvirnova, T.; Rauzy, A.; Theobald, M. Synchronization of system architecture, multi-physics and safety models. In Proceedings of the Tenth International Conference on Complex Systems Design and Management, CSDM 2019, Paris, France, 12–13 December 2019. [Google Scholar] [CrossRef] [Green Version]
  22. Batteux, M.; Prosvirnova, T.; Rauzy, A. System Structure Modeling Language (S2ML); 2015. Available online: https://hal.archives-ouvertes.fr/hal-01234903/document (accessed on 29 April 2021).
  23. Berriche, A.; Mhenni, F.; Mlika, A.; Choley, J.-Y. Towards Model Synchronization for Consistency Management of Mechatronic Systems. Appl. Sci. 2020, 10, 3577. [Google Scholar] [CrossRef]
  24. Demachy, R.; Guilmeau, S. Structural consistency of MBSE and MBSA models using Consistency Links. In Proceedings of the Embedded Real Time Systems, ERTS 2022, Toulouse, France, 1–2 June 2022. [Google Scholar]
  25. Grothendieck, A. Sur quelques points d’algèbre homologique, I. Tohoku Math. J. 1957, 2, 119–221. [Google Scholar] [CrossRef]
  26. Spivak, D.I. Category Theory for the Sciences; Massachusetts Institute of Technology, Ed.; The MIT Press: Cambridge, MA, USA, 2014. [Google Scholar]
  27. Schultz, P.; Spivak, D.I.; Vasilakopoulou, C. Dynamical Systems and Sheaves. Appl. Categ. Struct. 2020, 28, 1–57. [Google Scholar] [CrossRef] [Green Version]
  28. Ehresmann, A.C. MENS, an info-computational model for (Neuro-)Cognitive systems capable of creativity. Entropy 2012, 14, 1703–1716. [Google Scholar] [CrossRef]
  29. Ernadote, D. MB 2 SE: A Theoretical Foundation for Systems Engineering—Une Fondation Theorique Pour l’Ingenierie Systeme. HDR Thesis, Université Paris-Saclay, Gif-sur-Yvette, France, 2020. [Google Scholar] [CrossRef]
  30. Abdeljabbar, N.; Mhenni, F.; Choley, J.-Y. A Categorical Framework for Collaborative Design of Safety Critical Mechatronic Systems. In Proceedings of the 7th IEEE International Symposium on Systems Engineering, ISSE 2021, Vienna, Austria, 13 September–13 October 2021. [Google Scholar] [CrossRef]
  31. Ackerman, E.; Michael, K. Zipline’s Medical Delivery Drones are changing the game in Rwanda, The blood is here. IEEE Spectr. 2019, 56, 24–31. [Google Scholar] [CrossRef]
  32. Hagberg, A.; Schult, D.; Swart, P. NetworkX Reference (Release 2.7.1). 2011. Available online: https://networkx.org/ (accessed on 29 April 2021).
  33. Rauzy, A.; Haskins, C. Foundations for model-based systems engineering and model-based safety assessment. Syst. Eng. 2019, 22, 146–155. [Google Scholar] [CrossRef]
  34. Rauzy, A.B. Model-Based Reliability Engineering. Available online: http://www.altarica-association.org/members/arauzy/Publications/pdf/Rauzy2022-MBREBook.pdf (accessed on 29 April 2021).
Figure 1. Model synchronisation approach.
Figure 1. Model synchronisation approach.
Applsci 12 05880 g001
Figure 2. Illustration of a natural transformation.
Figure 2. Illustration of a natural transformation.
Applsci 12 05880 g002
Figure 3. Illustration of the cone and limit.
Figure 3. Illustration of the cone and limit.
Applsci 12 05880 g003
Figure 4. Structure of the pullback.
Figure 4. Structure of the pullback.
Applsci 12 05880 g004
Figure 5. Structure of a connection with two ports in a block/model.
Figure 5. Structure of a connection with two ports in a block/model.
Applsci 12 05880 g005
Figure 6. Example of a system model.
Figure 6. Example of a system model.
Applsci 12 05880 g006
Figure 7. Diagram of the system block from Figure 6.
Figure 7. Diagram of the system block from Figure 6.
Applsci 12 05880 g007
Figure 8. Diagram of the system model from Figure 6.
Figure 8. Diagram of the system model from Figure 6.
Applsci 12 05880 g008
Figure 9. An injection between two models.
Figure 9. An injection between two models.
Applsci 12 05880 g009
Figure 10. The structure of a binary consistency relation.
Figure 10. The structure of a binary consistency relation.
Applsci 12 05880 g010
Figure 11. Structure for binary consistency relations.
Figure 11. Structure for binary consistency relations.
Applsci 12 05880 g011
Figure 12. Illustration of the Zipline Flyer drone.
Figure 12. Illustration of the Zipline Flyer drone.
Applsci 12 05880 g012
Figure 13. A part of the SysML model (b) and its translation in the S2ML model (a).
Figure 13. A part of the SysML model (b) and its translation in the S2ML model (a).
Applsci 12 05880 g013
Figure 14. A part of the AltaRica 3.0 model (b) and its translation in the S2ML model (a).
Figure 14. A part of the AltaRica 3.0 model (b) and its translation in the S2ML model (a).
Applsci 12 05880 g014
Figure 15. A part of the Modelica model (b) and its translation in the S2ML model (a).
Figure 15. A part of the Modelica model (b) and its translation in the S2ML model (a).
Applsci 12 05880 g015
Figure 16. Diagrams for the S2ML models of the fixed-wing drone during iterations of SmartSync over the architecture and safety models.
Figure 16. Diagrams for the S2ML models of the fixed-wing drone during iterations of SmartSync over the architecture and safety models.
Applsci 12 05880 g016
Figure 17. Diagrams for the A and B S2ML models of the fixed wing drone at the final comparison step.
Figure 17. Diagrams for the A and B S2ML models of the fixed wing drone at the final comparison step.
Applsci 12 05880 g017
Figure 18. The pullback of A c o m p and B c o m p with regards to the dictionary.
Figure 18. The pullback of A c o m p and B c o m p with regards to the dictionary.
Applsci 12 05880 g018
Figure 19. The categories for both possible levels of abstraction of the gear motor.
Figure 19. The categories for both possible levels of abstraction of the gear motor.
Applsci 12 05880 g019
Figure 20. An example of block diagrams for a system with composed connections (left) that could be consistent with one connection (right).
Figure 20. An example of block diagrams for a system with composed connections (left) that could be consistent with one connection (right).
Applsci 12 05880 g020
Figure 21. Diagrams of the categories for the block diagrams from Figure 20.
Figure 21. Diagrams of the categories for the block diagrams from Figure 20.
Applsci 12 05880 g021
Table 1. Correspondence table for the first iteration of the comparison between the SysML and AltaRica 3.0 models.
Table 1. Correspondence table for the first iteration of the comparison between the SysML and AltaRica 3.0 models.
ZippyFlyerAvionicsBatteryCalculatorCellInertial_measurement_unitPower_unitRadar
Alternative_11.00.00.00.00.00.00.00.0
AirAction−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.1
Battery0.00.01.00.00.00.00.00.0
Data_in−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.1
Data_out−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.1
Ener_elec−1.0−1.0−1.00.0−1.0−1.0−1.0−1.1
Gravity−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.0
Obstacle_image−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.0
Orientation−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.0
Blood_bag−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.0
4G_network−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.0
Geolocation_signak−1.0−1.0−1.0−1.0−1.0−1.0−1.0−1.0
Avionics0.01.00.00.00.00.00.00.0
Calculator0.00.00.01.00.00.00.00.0
Cell0.00.00.00.01.00.00.00.0
Inertia_measurement_unit0.00.00.00.00.01.00.00.0
Power_unit0.00.00.00.00.00.01.00.0
radar0.00.00.00.00.00.00.01.0
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Vidalie, J.; Batteux, M.; Mhenni, F.; Choley, J.-Y. Category Theory Framework for System Engineering and Safety Assessment Model Synchronization Methodologies. Appl. Sci. 2022, 12, 5880. https://doi.org/10.3390/app12125880

AMA Style

Vidalie J, Batteux M, Mhenni F, Choley J-Y. Category Theory Framework for System Engineering and Safety Assessment Model Synchronization Methodologies. Applied Sciences. 2022; 12(12):5880. https://doi.org/10.3390/app12125880

Chicago/Turabian Style

Vidalie, Julien, Michel Batteux, Faïda Mhenni, and Jean-Yves Choley. 2022. "Category Theory Framework for System Engineering and Safety Assessment Model Synchronization Methodologies" Applied Sciences 12, no. 12: 5880. https://doi.org/10.3390/app12125880

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop