Kamdem Simo

Dominique Ernadote
email: dominique.ernadote@airbus.com

Dominique Lenne
email: dlenne@utc.fr

Freddy Kamdem Simo

On a federated architecture for utilizing domain-specific descriptive models *

In a Systems Engineering setting, various models are produced using a variety of methods and tools. Focusing on a type of models -called descriptive models -which we shall describe, we argue that, while the clarity and precision of models are essential for their exchange and reuse, the way in which the data of these models are defined and the information conveyed is also essential for their (re) utilization -e.g., for analysis or synthesis purposes. Category Theory has made it possible to link seemingly separate fields or domains, so that anything that can be rewritten in this framework benefits from a level of abstraction and a relational viewpoint -essential to address complexity. We therefore take advantage of this framework to define a federated architecture for projecting and conveying these models without sacrificing clarity and precision. A federated architecture has two important advantages. On the one hand, it unifies these models from their structure; on the other hand, it allows a specific usage (instantiation or interpretation) of this structure within a business domain. We define the structure of these models as a symmetric multicategory. In particular, we rely on matrices over a semiring to define morphisms and their composition. The choice of matrices is intended to facilitate the application in practice.

1 Challenges with metamodels, data formats, interfaces and mappings

In a Systems Engineering setting, a model of a System-Of-Interest often refers to a partial, but necessary, view or aspect of that system, in pursuit of a goal. This model is not always based on a theory and need not be in many cases, e.g., in creative, preliminary or general communication phases. However, when it is necessary to reason or compute on a model, the formal content (sometimes called semantics or business semantics) of that model should (mathematically) be defined in order to ensure sound reasoning. We shall see that such a definition is not enough to ensure that different implementations in modelling tools are equivalent or, ideally, functionally identical. In this paper, we focus on descriptive models -hereafter referred to simply as models, unless otherwise specified -by which we mean a model whose structureequipped with input and output interaction points -encodes the main (abstract) structure of the thing to be modelled. We examine how descriptive models produced using a particular tool might be re-utilized, for instance for analysis or synthesis purposes. The question is to what extent descriptive models can be decoupled from the logic of their implementation by a particular tool while retaining their full meaning and being reusable.

One solution for making models transferable and interoperable between some tools is to impose the following: i) a common metamodel, ontology, schema or modelling language; ii) a common data format; iii) a common interface. Metamodels support, through the definition of syntax, the graphical representation of models and descriptions of their semantics. However, when models are used outside the tool in which they originated, some assumptions present in the metamodels may be missing. For instance, Statecharts [START_REF] Harel | Statecharts: A visual formalism for complex systems[END_REF], a visual modelling technique, have a plethora of existing semantics implemented within tools, falling into three main categories [START_REF] Eshuis | Reconciling statechart semantics[END_REF]. Regarding the implementation of semantics by modelling tools, a missing assumption relating to a semantics will either be implicit in the metamodel, or explicit but proper to the modelling tool. It has been argued in [START_REF] Sanjit | Modeling for verification[END_REF] that even for the same modelling formalism, that is to say a mathematical object, different implementations (via an abstract syntax and a semantics) may exist, and so the implementation of the same semantics is not guaranteed. In addition it has been pointed out in [START_REF] Diskin | Category theory and model-driven engineering: from formal semantics to design patterns and beyond[END_REF] that it is hard to mathematically classify the numerous modelling languages and techniques, and that a number of MDE (Model-Driven Engineering) approaches are not grounded on formal semantics.

As for the data format, it is intrinsically related to the structure of data of models. Using a particular data format is useful when persisting models. The data format does not influence the semantics of a model.

An interface can be useful for manipulating models, but the question of how to define this interface remains. As with the above-mentioned problems with metamodels, it is necessary to ensure that the internal implementation associating to an interface reflects the modelling formalism. Indeed, when several implementations coexist, it is not certain that they behave in the same way. In the latter case, the only solution might be to use the same implementation -like software libraries.

One might also think of mappings, translations or transformations between different metamodels, formats and interfaces. When feasible, this would imply the same problems -managing of mappings and even new metamodels, formats or interfaces acting as bridges -as with models. In some cases, although the magnitude of mappings or translations can be quadratic or linear (in the number of metamodels, for instance), it may be impossible (different tools specializing in different fields) or inappropriate (e.g. too expensive) to create or define a mapping. In order to address these various issues, this paper introduces and specifies a novel Federated Architecture (FA) for handling descriptive models.

In Section 2 we present our main idea, as well as a description of FA, and give some reasons (others are presented in Section 4) for adopting the category theory framework. In Section 3 we then give a formal definition of FA. In Section 4 we discuss the relevant related work. In Section 5, we present some concluding remarks.

Main idea: encapsulation-differentiation

It turns out from Section 1, that whatever the common interface, metamodel or data format used between tools, clarity and precision are not the only essential features. In today's software-intensive and computer-aided environments, the way in which models can be defined and conveyed is also essential since this has a direct impact on interoperability. We consider this a question that is better addressed at the level of the architecture of models. We adopt the ISO/IEC/IEEE 420101 standard, which defines the architecture of any system as the abstract description or the fundamental organization of that system, embodied in its components, the relations of those components to each other and to the environment, and the principles governing the design and evolution of that system.

FA is federated in that while it is based on a specific structure, it makes it possible to define domain specific-models via instantiations and interpretations -usages -of that structure. FA therefore unifies models on their structure and the links from the structure to its usages. FA equally differentiates models through domain-specific interpretations. Below we look at the basic organisation and principles governing the definition of a descriptive model.

Structure of a model Above we define a descriptive model as one whose structure -equipped with input and output interaction points -encodes the main (abstract) structure of the thing to be modelled or designed. This structure consists of boxes linked with incoming and outgoing wires. Input and output interaction points are ports associated to boxes ensuring connection with their surrounding environment. A representation of a tricky system can be managed using hierarchical decompositions and re-compositions.

Interpretations of the structure Since many systems are usually studied from different perspectives, namely: human, physical, structure, behaviour, cost, safety, etc., then different interpretations of their structure(s) are possible and necessary. At the level of models, these interpretations yield domain-specific languages or semantics. A structure hence constrains the definition of its interpretation, even if possible interpretations of the structure cannot be known by examining it per se. It may consequently be difficult, if not impossible, to impose or foresee all possible interpretations of the structure of a model. What is needed is a means of using that structure appropriately, and this starts with a clear and precise definition of that structure.

Instances of the structure Utilizing a structure involves data relating to an actual (or candidate) system that is modelled. These data should also relate to an interpretation of the structure, meaning that their precise meaning can be known and that they can be utilized.

The main components of FA are therefore (a) the model's structure; (b) the interpretations of the structure; (c) the corresponding instances of the structure. The architecture needs to support the ability (or to provide means) to define various interpretations of boxes. It does not model a concrete interpretation of them, but we will present some principles or guidelines for creating an interpretation. The same remark applies to instances of the structure.

Trivial example suppose the system is a research paper like the present one. A Structure of the paper comprises 8 boxes (that is to say, sections, including Abstract, References and Appendix). The paper itself is seen as a composite section that embodies these 8 sections. An Instance of this structure can be given by providing each section's title, size, or content. An interpretation of this structure might be a definition of what the size of (constituent and composite) boxes means. Note that this example does not consider the internal wiring pattern of composite boxes (sections).

Why the category theory framework? Category theory was created to unify and simplify mathematical systems [START_REF] Mac | Categories for the working mathematician[END_REF] and has given rise to some universal constructions based on a relational viewpoint. This framework enables us to i) naturally define the notion of composite-box with its constituent-boxes via an arrow in a category; ii) abstract away details relating to a particular interpretation of the structure of models. At the same time, it allows a formal link to be specified between the structure of models and various targets like Instances and Interpretations. This formal link is ideally defined as a functor. We discuss further in Section 4.2, comparing and drawing on related work, why category theory seems to be the framework for appropriately defining FA. Besides the framework can guide us towards possible canonical extensions of FA with the enrichment of objects and category structure, see Section 5.

Components of FA

We define the structure of models in Section 3.1, and discuss the interpretation and usage of this structure in Section 3.2 and Section 3.3 respectively. To be able to define the structure of a model as a category, the objects will be the boxes and the arrows will show how boxes are linked to create composite boxes. Defining the structure of models as a symmetric multicategory denoted Msc is done in two stages. We start by defining a symmetric monoidal category (SMC) denoted (Mscm, ⊗, I) and prove that it is indeed an SMC. We then derive Msc using results from [START_REF] Leinster | Higher Operads, Higher Categories[END_REF]. Since we will be using matrices to define the composition in Mscm, we may be able to derive a further symmetric multicategory denoted MatMsc, where arrows are given by matrices that might be useful for computations.

Structure of models

Why is it not enough simply to derive an SMC? Consider the box Y in Figure 1, composed of 2 boxes X 1 and X 2 . In an SMC Y can be seen to be composed of X 1 ⊗ X 2 (i.e. there is an arrow X 1 ⊗ X 2 → Y ), yielding Figure 2. Figure 1 is a lot clearer than Figure 2, in which the modularity (i.e. the clear distinction between X 1 and X 2 in Y ) is not reflected graphically. Figure 1 corresponds to an arrow X 1 , X 2 → Y in the multicategory. However, it is more convenient to use the SMC than the multicategory insofar as subscripts can be avoided.

The box and arrow representation that we use should not be confused with string diagrams [START_REF] Selinger | A survey of graphical languages for monoidal categories[END_REF]. String diagrams are a graphical language of categories [START_REF] Selinger | A survey of graphical languages for monoidal categories[END_REF] in which the objects and morphisms of categories are represented by wires and boxes respectively. In our paper, on the other hand, objects correspond to boxes, and morphisms correspond to how composite boxes are internally built (using wiring patterns) with its constituent boxes.

Figure 1 looks like a Wiring Diagram WD [19] [24], but in fact it differs from a WD in the following respects. In figure 1 we allow unconnected ports (ports without incoming or outgoing wires), converging wires (separate wires with the same target port), and diverging wires (same source port). Unconnected ports and converging wires are prohibited in a WD. Figure 1 would also allow several links between a source port and a target port. WDs may therefore be considered as special cases of figure 1 that include certain restrictions; this is discussed in Section 4.2. The point of allowing these various things is to encompass as many wiring patterns as possible that may occur in practice. For instance, it might be the case, structurally, that an actual component is not plugged into its surrounding environment via any of its interfaces. See for instance a simple Ptolemy model [23, Figure 9], similarly permissive.

θ in : L in → in(b) × (out(b) ∪ in(a)) θ out : L out → out(a) × out(b) (1)
where L in and L out are the abstract finite sets of links coming respectively into an input port and an output port of one of the boxes b and a.

We require that R2: L in , L out ∈ K and L in ∩ L out = / 0. (K, ∪, •, / 0, {ε}) is a semiring introduced below to define composition using matrices and detailed in Appendix (Section 6). We additionally require that R3: the domains (or more precisely L in ∪ L out ) of the set of morphisms be pairwise disjoint. R1, R2 and R3 ensure that objects and morphisms are all unambiguously defined. This will also be important in the definition of the monoidal product. Note also that (1) does not allow a link to go from an output port of a to one of its input ports. This is a modelling choice consistent with the fact that any box only exposes its input and output ports. An arrow is intended to give the internal wiring pattern of a composite box. A link that goes from an output port of a to one of its input ports should, rather, give rise to a new object a and a new arrow a → a which models a kind of self-feedback, see Figure 4. In the same way, (1) does not allow a link to go directly from an input port of a to an output port. This is also a modelling choice that allows us to consistently zoom in on a composite box, avoiding the presence of isolated links when applying composition. If there were an isolated link, we would simply need to create a basic box with one input port and one output port and link them to the input and output ports respectively of a, such that this box outputs onto its output port the data that comes into its input port.

Example Consider Figure 3. We have two boxes X and Z given by ({a, b}, {c, d}) and ({i, j}, {k, l}) respectively. There is an arrow X → Z given by ({l 1 → (a, c), l 2 → (b, i), l 3 → (b, j)},{l 4 → (k, c), l 5 → (l, d)}).

• Identities Mscm(a; a). An identity a 1 a -→ a consists of θ in and θ out given by (1 in a , 1 out a ) := ({lin i → (i, i), i ∈ in(a)}, {lout j → ( j, j), j ∈ out(a)}) ; i.e. links connect identical (input to input and output to output respectively) ports from the domain (a) to the codomain (a) of 1 a .

• Composition formula •. Composition enables a constituent of a composite box to be replaced by a more detailed constituent(s). For boxes a, b, c ∈ Mscm 0 , we have a function •:

Mscm(b; a) × Mscm(c; b) → Mscm(c; a).
We must define an arrow c θ •θ 1 --→ a. This amounts to finding a function θ 0 := θ • θ 1 , i.e. θ in 0 and θ out 0 following [START_REF] Blochwitz | Functional mockup interface 2.0: The standard for tool independent exchange of simulation models[END_REF].

In order to define the composition formula, we use matrix operations. We start by establishing a connection between arrows and certain matrices over a semiring (K, ∪, •, / 0, {ε}); see Appendix 6 for more details. We are now ready to work with the matrix representation of an arrow.

The data (1) of an arrow can be rewritten as follows (see Appendix 6). We define

M out : Y in × (Y out ∪ Z in ) → 2 L in M in : Z out ×Y out → 2 L out (2)
where

Y in = in(b), Y out = out(b), Z in = in(a) and Z out = out(a). 2 L is the powerset. Let X in = in(c), X out = out(c).
We denote / 0 M as the matrix with / 0's everywhere and I M the square matrix with {ε}'s on the main diagonal and / 0's elsewhere. Given [START_REF] Hardebolle | ModHel'X: A component-oriented approach to multiformalism modeling[END_REF] in Appendix 6 and the above notations, we are now ready to define arrow composition.

The map θ • θ 1 (i.e., c θ 0 -→ a in Mscm) of an arrow is rewritten as (O in , O out ), given by the dashed arrows in the following diagrams. In accordance with Appendix 6 an arrow I M -→ J in this diagram defines the matrix M(I, J).

X in N in O in / / Z in ∪ X out Y in ∪ X out M in / / Z in ∪Y out ∪ X out N out O O Z out O out / / M out X out Y out N out 9 9 O out = M out × N out O in = N in × M in × N out (3)
where N in , N out , M in are respectively given by:

Y in ∪ X out ( ) X in N in Z in X out Z in I M / 0 M Y out / 0 M N out X out / 0 M I M Z in ∪Y out X out Y in M in / 0 M X out / 0 M I M
and M out , N out are respectively given by:

Y out ( ) Z out M out X out ( ) Y out N out
M out = g h k {l 1 } / 0 l / 0 {l 2 } N out = c d g {l 3 } / 0 h / 0 {l 4 } N in = e f c d a / 0 / 0 {l 5 } / 0 b {l 6 } / 0 / 0 / 0 N out = i j c d               i {ε} / 0 / 0 / 0 j / 0 {ε} / 0 / 0 g / 0 / 0 {l 3 } / 0 h / 0 / 0 / 0 {l 4 } c / 0 / 0 {ε} / 0 d / 0 / 0 / 0 {ε} M in = i j g h c d       e {l 7 } {l 8 } / 0 / 0 / 0 / 0 f / 0 / 0 / 0 {l 9 } / 0 / 0 c / 0 / 0 / 0 / 0 {ε} / 0 d / 0 / 0 / 0 / 0 / 0 {ε}
It is easy to check that O out = M out × N out and O in = N in × M in× N out are given by the following matrices:

O out = c d k {l 1 l 3 } / 0 l / 0 {l 2 l 4 } O in = i j c d a / 0 / 0 {l 5 } / 0 b {l 6 l 7 } {l 6 l 8 } / 0 / 0
The composition in this example enables us to zoom in on Z, in other words to know how Z is built from X, itself a constituent box of Y . After the composition the link in Figure 5 (a representation of the two arrows X -→ Y , and the way • acts on links (or elements of K) in the semiring (K, ∪, •, / 0, {ε}). In practice this could mean that f is not connected, even though it appears to be.

Proposition 3.1. The identity law holds for the constituents of Mscm.

Proof. The matrices corresponding to θ • 1 b and 1 a • θ are seen to be equal to the matrix corresponding to θ , whenever θ : b → a is an arrow. Proposition 3.2. The associativity law holds for the constituents of Mscm.

Proof. The associativity law follows from the associativity of matrix multiplication. Now we define the monoidal product of Mscm.

Definition 3.2. Let X 1 , X 2 ,Y 1 ,Y 2 and θ 1 : X 1 → Y 1 , θ 2 : X 2 → Y 2 be
objects and arrows respectively of Mscm. The monoidal product (or tensor product) ⊗ : Mscm × Mscm → Mscm is given by:

X 1 ⊗ X 2 := (in(X 1 ) ∪ in(X 2 ), out(X 1 ) ∪ out(X 2 )), θ 1 ⊗ θ 2 := θ 1 ∪ θ 2 (4)
The unit I is the box without input and output ports i.e. I:=( / 0, / 0). R2 and R3 ensure that θ 1 ⊗ θ 2 is well-defined.

Note here that the effect of the tensor on different objects and arrows is simply to stack them straightforwardly and without losing (thanks to R1, R2 and R3) the origins of ports and links. For instance, stacking the unit I with any non-unit object X will have no effect on X, since the box corresponding to I does not have any input or output ports. The effect of tensor on the same object (resp. arrow) is: stacking a box (resp. an arrow) with itself has no effect, i.e., results in the same object (resp. arrow).

Proposition 3.3. ⊗ : Mscm × Mscm → Mscm is a (bi)functor.
Proof. ⊗ preserves identity morphisms and composition of morphisms. It suffices to write the corresponding morphisms, i.e. let

X 1 , X 2 ,Y 1 ,Y 2 , Z 1 , Z 2 and α 1 : Y 1 → Z 1 , α 2 : Y 2 → Z 2 , θ 1 : X 1 → Y 1 , θ 2 : X 2 → Y 2 be

objects and arrows respectively of Mscm

Identity ⊗(1 X 1 , 1 X 2 ) = 1 X 1 ∪ 1 X 2 = X 1 ∪ X 2 1 X 1 ∪X 2 ---→ X 1 ∪ X 2 = 1 ⊗(X 1 ,X 2 ) Composition ⊗(α 1 • θ 1 , α 2 • θ 2 ) = ⊗(X 1 α 1 •θ 1 ---→ Z 1 , X 2 α 2 •θ 2 ---→ Z 2 ) = X 1 ∪ X 2 (α 1 •θ 1 )∪(α 2 •θ 2 ) ---------→ Z 1 ∪ Z 2 and ⊗(α 1 , α 2 ) • ⊗(θ 1 , θ 2 ) = (Y 1 ∪Y 2 α 1 ∪α 2 ---→ Z 1 ∪ Z 2 ) • (X 1 ∪ X 2 θ 1 ∪θ 2 ---→ Y 1 ∪Y 2 ) = X 1 ∪ X 2 (α 1 •θ 1 )∪(α 2 •θ 2 ) ---------→ Z 1 ∪ Z 2
Proposition 3.4. The category (Mscm,⊗,I) with the constituents given in Definition 3.1 and the tensor product given in Definition 3.2 is a symmetric monoidal category.

Proof. We have already shown that Mscm is a category (see Definition 3.1, Proposition 3.2 and Proposition 3.2). It remains to show that the tensor product is effectively a symmetric monoidal structure on Mscm.

Given X 1 , X 2 , X 3 ∈ Mscm 0 , we have

(X 1 ⊗ X 2 ) ⊗ X 3 = X 1 ⊗ (X 2 ⊗ X 3 ) (associativity) I ⊗ X 1 = X 1 = X 1 ⊗ I (le f t and right units) X 1 ⊗ X 2 = X 2 ⊗ X 1 (commutativity) (5)
The associator, unitors and inverse map (braiding) are identities.

Proposition 3.5. Msc is an underlying symmetric multicategory of (Mscm,⊗). Its objects are the same objects as Mscm, and its arrows are the set Msc(a 1 , ...., a n ; a). An arrow a 1 , ...., a n → a is defined as an arrow a 1 ⊗ • • • ⊗ a n → a in Mscm.

Proof. Any monoidal category (A,⊗) has an underlying multicategory C [12, Example 2.1.3]. Moreover, any symmetric monoidal category is naturally a symmetric multicategory, via the symmetry maps σ • -:

a σ (1) ⊗ • • • ⊗ a σ (n) - → a 1 ⊗ • • • ⊗ a n .[12, Definition 2.2.21]
Example In Figure 1, there is an arrow X 1 , X 2 → Y in Msc, which is defined as

X 1 ⊗ X 2 → Y in (Mscm,⊗).
Since we rely on matrix multiplication to define composition in Mscm, we can redefine the components of Msc using matrix without altering their initial meaning. This might be useful to automate computations with morphisms. Again a connection between morphisms of Mscm and certain matrices over a semiring is presented in Appendix 6. Definition 3.3. MatMsc is an underlying symmetric multicategory of (Mscm,⊗).

• Its objects are the same objects as Mscm. An object X is rewritten as (X in , X out ).

• Its arrows MatMsc(a 1 , ...., a n ; a). An arrow a 1 , ...., a n → a is rewritten as follows

. Let b = a 1 ⊗ • • • ⊗ a n , X in = in(b), X out = out(b), Y in = in(a)
and Y out = out(a), the arrow b → a in Mscm, noted X → Y is given by the couple of matrices (M in , M out ) where M in and M out are given by the functions X in × (Y in ∪ X out ) → K and Y out × X out → K respectively. Objects and arrows are subject to R1, R2 and R3 as in Mscm.

• Identities MatMsc(a; a). For any object (X in , X out ), the identity arrow

1 X := (1 in X : X in × (X in ∪ X out ) → K, 1 out X : X out × X out → K), rewritten as follows. 1 in X yields X in X out ( ) X in I M / 0 M and 1 out X yields X out ( ) X out I M
• The composition formula is the same as for Mscm, but rewritten as follows. Consider the objects X, Y , Z and arrows n : X → Y and m : Y → Z given by matrices (N in , N out ) and (M in , M out ) respectively. The arrow m • n : X → Z is given by (O in , O out ):

O in = N in × M in × N out O out = M out × N out
The identity law holds in MatMsc with this rewriting (already shown in relation to

Mscm) i.e. m • 1 X = m = 1 Y • m whenever m : X → Y is an arrow. The matrices defining m • 1 X and 1 Y • m are both equal to M i.e. (M in , M out ). The arrow m • 1 X associates M to m and N to 1 X . Therefore O in equals N in × M in × N out = X in X out ( ) X in I M / 0 M × Y in ∪ X out X out X in M in / 0 M X out / 0 M I M × Y in X out Y in I M / 0 M X out / 0 M I M X out / 0 M I M O in is indeed equal to M in . We also have O out equals M out × N out = X out ( ) Y out M out × X out ( ) X out I M O out is equal to M out . Hence, m • 1 X = m. In the same way: m = 1 Y • m.
MatMsc can be seen as the category where objects declare interfaces and where morphisms declare how composite interfaces are internally built from other interfaces. The composition formula lets us safely zoom in and zoom out on levels further down and up in the hierarchy of interfaces.

It is worth noting that with only MatMsc (or Msc or Mscm), no meaning (related to a domain of interest or business domain) is assumed for an interface, its ports and, if applicable, its internal links.

Interpretations of the structure

The present section proposes an approach that seeks to bridge the gap between a possible semantics (interpretation of the structure) and its implementation in practice. A semantics corresponding to an interpretation of the structure may be formally defined in a variety of ways (denotational, axiomatic, operational, etc.) and with numerous possibilities of implementation. This paper is not concerned with defining or implementing a particular semantics, but sets out principles for formally connecting the structure, semantics and their implementation. As mentioned above, the architecture of a system is not about the effective (or final) implementation of the system.

Using the structure of models, it is possible to specify an interpretation of boxes such that the associated semantics can be recovered. An actual interpretation could therefore be independently developed by using the structure of models. Ideally, the specification of the interpretation is given by a functor F : Msc → Msin, Msin being the category in which the structure is interpreted. The caveat 'ideally' is necessary, because it may not always be straightforward to define a functorial semantics.

Examples (i) Consider once again a model corresponding to the box shown in Figure 1. A domain-specific meaning of this model can only be known once the definition of an interpretation of its structure is given. Let us suppose that the domain of interest is classical physics and that we wish to study some physical properties of boxes. In this case, F can be defined as F : Msc → Msin. Let Msin :=Set. Along with objects, set of real numbers, and arrows, n-ary functions define the relationship between a physical property of a box and the physical properties of its n constituent boxes. F is a map of multicategories and an algebra for Msc (See [12, Definition 2.1.9, Definition 2.1.12]). Here, let us take mass to be the physical property under consideration.

Let F be F 0 :

{X 1 , X 2 ,Y } → R >0 given by X → ma. The image of X 1 , X 2 → Y is the function F 0 (X 1 ) × F 0 (X 2 ) → F 0 (Y ) given by (ma 1 , ma 2 ) → ma.
Depending on the meaning of links, ma can be equal either to (*) ma 1 + ma 2 or to (**) ma 1 + ma 2 + m L , m L ∈ R + . In the first case (*), the mass of a composite box will depend solely on the masses of its constituent boxes. In the second case (**), the mass of a box will additionally depend on m L , which is an additional mass emerging from internal connections.

Similar interpretations can be made for other physical properties.

(ii) Consider the arrow in Figure 6. Let each of the boxes X i , i = 1..4 be interpreted as a two-digit adder (d 0 + d 1 = cs) which returns the sum (s) and the carry (c) via the top and bottom output ports respectively, given d 0 and d 1 obtained from top and bottom input ports. Here, the containing box Y can The concept of mass in (i), and the concepts of two-digit adder and two-digit numbers adder in (ii), must be exposed by F, irrespective of how these concepts are defined in Msin and irrespective of the implementation. These data must be machine-accessible. It is worth noting that the functorial semantics of wiring diagrams (i.e. special cases of Msc) defined in [START_REF] Rupel | The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes[END_REF], [START_REF] David | The operad of wiring diagrams: Formalizing a graphical language for databases, recursion, and plug-and-play circuits[END_REF], [START_REF] Vagner | Algebras of open dynamical systems on the operad of wiring diagrams[END_REF] and [START_REF] David | Nesting of dynamic systems and mode-dependent networks[END_REF] are concerned with the interconnections of discrete-time processes, databases and plug-and-play circuits, differential equations of open dynamical systems, and mode-dependent networks respectively. In each case, a particular algebra is devised which may be implemented as definitions of interpretations of the structure of models.

Usages of the structure

If the structure of a model is to be automatically exchangeable, then in the same way that the definition of an interpretation of the structure needs to be machine-accessible, the related data must also be machineaccessible.

The data relating to an actual (or candidate) system modelled is defined by a Set-valued functor I : Msc → Set. This links an object a ∈ Msc 0 to the set of its usages I 0 (a), and any arrow a 1 , ..., a n θ -→ a ∈ C(a 1 , ..., a n ; a) to the function I 0 (a 1 ) × ... × I 0 (a n )

I(θ )
--→ I 0 (a). Taking the composition and the identity in the same way as in Set, I is a map of multicategories [12, Definition 2.1.9] and an algebra for Msc [12, Definition 2.1.12]. The usefulness of I stems from the fact that where the structure (Msc) of a model, together with at least one interpretation (F) of this structure, has been established, this is still not quite enough to allow the model to be used. The actual business data corresponding to the components of the structure are also required. For instance, consider the box shown in Figure 1 and the interpretation given in example (i) above. How do we communicate the fact that the masses of boxes X 1 and X 2 and Y are given by actual values? No assumptions are made concerning the relations between the different masses. A parallel can be drawn with databases: it is good to have a database schema and to know what tables correspond to in the real world, but in order to use a database we also need to know the contents of the tables (the actual data entries). The purpose of I is to answer this kind of question, by providing instances of the components of a structure of a model.

Let us recapitulate the purpose of the present section. We have provided an informal and a formal understanding of the proposed architecture FA. To be able to read a model (data), it is necessary to have at least the specification of I : Msc → Set, while to be able to utilize a model (semantics), it is necessary to have at least the specification of F : Msc → Msin. I and F are intended to facilitate the transfer of the modularity of Msc in different interpretations of Msc. Without functoriality, the modularity and the generality offered by the category-theoretic framework are lost (even though this functoriality is not always easily perceived, and may in some cases be unnecessary).

For exploiting models through a given automated routine, it is necessary to specify

Msin F ← -Msc I - → Set (6)
and make the definition of interpretation machine-accessible. Nonetheless, wherever the usage of a structure is linked to a particular interpretation of that structure, it can be argued that the effective data related to Msc should instead be given by an amalgamated sum (a pushout) over [START_REF] Droste | Semirings and Formal Power Series[END_REF].

4 Related research FMI2 (Functional Mockup Interface), the standard which attempts to solve the problem stated in Section 1, is discussed in Section 4.1. Then other relevant related works that can be correlated to FA are discussed in Section 4.2.

FMI

FMI is a tool-independent interface that allows models to be exchanged and inter-operated in a cosimulation. An FMU (Functional Mock-up Unit), one of the components of FMI, must implement the FMI API via XML files and C-code. In FMI a model is associated with a particular FMU, which is generated using different tools. The kinds of models covered by FMI are (co) simulation models [START_REF] Blochwitz | Functional mockup interface 2.0: The standard for tool independent exchange of simulation models[END_REF]. This paper is not primarily concerned with how models co-operate. Nevertheless, the way a model is defined (such as via an FMU) will influence how it can be reused.

An FMU separates the description of interface data (via an XML -Extensible Markup Languagefile) from its mode of operation (via a program written in the C programming language). The interface data describes the static elements of the model such as type definitions (Real, Integer etc.), model variables, model structure (an ordered list of outputs termed Outputs, states termed Derivatives), and some initially unknown data termed InitialUnknowns), along with units etc. The C-code and header files define the functions to be implemented by an FMU. These functions are used to simulate a model described according to a particular FMU. Generally speaking, the functions are for purposes such as initializing the FMU, assigning values to an input variable, retrieving the value of an output variable, changing the state of the FMU, etc. More information about the evolving specification of the FMI standard and supported tools can be found on the FMI website.

Although the FMI standard provides an interface to be implemented by FMUs, one concern is that there can be semantic gaps (studied in [START_REF] Tripakis | Bridging the semantic gap between heterogeneous modeling formalisms and FMI[END_REF] [START_REF] Cremona | FIDE: an FMI integrated development environment[END_REF]) between different model semantics (e.g, discrete events, dataflow models) or modelling languages and the target interface [START_REF] Tripakis | Compositionality in the Science of System Design[END_REF]. The semantics of the target interface has been considered as a timed Mealy machine [START_REF] Tripakis | Bridging the semantic gap between heterogeneous modeling formalisms and FMI[END_REF]. Another concern is the extent to which the interface can be used to capture the semantics of different kinds of models [START_REF] Tripakis | Compositionality in the Science of System Design[END_REF]. Attempts to address this problem have resulted in various (proposed) adaptations of FMI [START_REF] Cremona | FIDE: an FMI integrated development environment[END_REF] [START_REF] Cremona | Hybrid co-simulation: it's about time[END_REF]. Therefore, the specification and definition of the common interface are crucial. The FMI standard is mainly concerned with the exchange of models and their simulation as black boxes.

In this paper we adhere to the FMI standard in separating structure and function. But, unlike in FMI, we give a formal definition of FA. The structures of models are considered as composite components defined within a category-theoretic framework, and a predefined interface for the implementation of functions is not imposed. Any implementation has to be derived from an interpretation of the structure of models. The (software) code corresponding to an implementation must expose the functions whose inputs and outputs are correlated to an interpretation of the structure. The data corresponding to the instantiations (i.e. actual serialized models) of the structure are elements that should be persisted as a file.

Other works

The kind of descriptive model that we are talking about is close, in terms of model structure (or abstract syntax), to the component-based, modular, and even composite-like models that are habitually encountered in system and software modelling, simulation, and more generally, analysis. See for instance [START_REF] Hardebolle | ModHel'X: A component-oriented approach to multiformalism modeling[END_REF] [23] for approaches and tools that deal with this kind of model structure. Although these approaches address modelling and simulation, their ultimate aim is not to solve the problem that is our concern here. They generally introduce their own approach (mainly on modelling formalisms) to system modelling and analysis. Metamodels for this kind of structure have been presented by [START_REF] Edward | Disciplined heterogeneous modeling[END_REF] [START_REF] Hardebolle | ModHel'X: A component-oriented approach to multiformalism modeling[END_REF]. Their approaches advocate hierarchical and component-based design in systems modelling and engineering.

From a practical (yet formal) point of view, a box (a component of FA) is analogous to an actor in [START_REF] Tripakis | A modular formal semantics for Ptolemy[END_REF]. In [START_REF] Tripakis | A modular formal semantics for Ptolemy[END_REF], boxes are encoded using the logic of the modelling tool Ptolemy and the Java programming language. This may hamper the reuse of models, albeit some of these models may be imported using FMI.

In the present paper, unlike in [START_REF] Tripakis | A modular formal semantics for Ptolemy[END_REF], a box does not correspond to a particular semantics (i.e. the target of an interpretation of the structure). For [START_REF] Tripakis | A modular formal semantics for Ptolemy[END_REF], boxes or actors are seen as extended timed state machines, since the authors' focus is on behavioural models. The corresponding semantics is also called the actor interface, defined in a way that includes both the structure and the semantics of the box. However, the actor interface can also be considered as the target of an interpretation of the structure of a box, since the input and output ports of a box are explicit in this interface. In [START_REF] Tripakis | A modular formal semantics for Ptolemy[END_REF] composite actors are basically considered as a set of actors, whereas for us a composite box is an arrow in Msc (see Section 3). It will be noted that [START_REF] Tripakis | A modular formal semantics for Ptolemy[END_REF] is mainly concerned with a unified description of the behavioural semantics of a composite that comprises more than one actor.

It might be suggested that graphs are a way of formalizing the structure of models. Although graphs are very useful in representing interconnected objects, they lack the sort of intrinsic feature for dealing with the hierarchical composite structure of vertices (in the present context vertices equate to boxes) that we require. In order to represent this kind of structure, the graph would need to include additional data, which might complicate the formalization.

In fact, hierarchical graphs have also been formalized in category theory to model hierarchical structures [START_REF] Milner | Bigraphs and Their Algebra[END_REF] (where coupling of hyper-graphs and forests yields bigraphs) [START_REF] Bruni | Hierarchical Models for Service-Oriented Systems[END_REF] (graphs inside graphs). Although hierarchical graphs encapsulate the hierarchy of nodes (here, boxes) and the communication links between nodes, the nature and structure of nodes and node containment (nesting) and links between nodes do not have the same meaning as described in Section 2. In the present work a node is given by input and output ports. The source and target of a link are ports at the same level of hierarchy of a box. We do not use two separate structures to define boxes (objects) and as a basis for composite boxes (arrows), and in this our approach contrasts with the two-structure approaches of [START_REF] Milner | Bigraphs and Their Algebra[END_REF] (place graph and linking graph ) and [START_REF] Bruni | Hierarchical Models for Service-Oriented Systems[END_REF] (graph layer and hierarchical graph).

Our inspiration for the category structure considered in this paper is, rather, to be found in [START_REF] David | The operad of wiring diagrams: Formalizing a graphical language for databases, recursion, and plug-and-play circuits[END_REF] [16], [START_REF] Vagner | Algebras of open dynamical systems on the operad of wiring diagrams[END_REF] and [START_REF] Luzeaux | A Formal Foundation of Systems Engineering[END_REF]. [START_REF] Luzeaux | A Formal Foundation of Systems Engineering[END_REF] considers symmetric monoidal and compact closed categories, with associated logics and proof theories as a possible formal foundation for systems engineering, given that it is compatible with current modelling languages and tools and encompasses existing formalisms. The mathematical object presented in this paper for encapsulating the structure of models, a symmetric multicategory (see Section 3), is closely related to the Wiring Diagrams (WD) structure developed in a series of papers: [START_REF] Rupel | The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes[END_REF], [START_REF] David | The operad of wiring diagrams: Formalizing a graphical language for databases, recursion, and plug-and-play circuits[END_REF], [START_REF] Vagner | Algebras of open dynamical systems on the operad of wiring diagrams[END_REF] etc. The two big differences between the WD structure and our structure are the following:

(i) Our structure is a more general construction supported by the "wiring" or connection pattern, i.e. almost all possible ways of connecting sub-components (or constituents) of a composite component are allowed, unlike WD (see Section 3.1 below for details of what WD does not allow). A WD is basically given by (X in + X out ) -→ (Y in + X out ) ← -(Y in +Y out ) [START_REF] Andrée | Hierarchical Evolutive Systems: A mathematical model for complex systems[END_REF] which can be decomposed into two functions

φ in : X in → Y in + X out φ out : Y out → X out (8)
To obtain (1) -our definition -from ( 8), the elements of φ in and φ out must be associated to the abstract sets of links or wires L in and L out . To get (8) from (1) it is necessary to have θ in and θ out of (1) that are injective. The elements of L in and L out can be seen as the labels of wires.

(ii) We are not concerned with a particular interpretation (e.g. an algebra) of the structure of models.

Summary and perspective

Our aim was to provide a federated architecture for descriptive models in order to facilitate their development, sharing and utilization. Though clear and precise definitions of models are essential, how such definitions are conveyed in practice, particularly in distributed, collaborative and computer-aided environments, is also essential, and crucial to some extent. In order to bridge the gap between theoretical and practical considerations, a federated architecture (FA) was presented via the specification: [START_REF] Droste | Semirings and Formal Power Series[END_REF]. Categorical settings are useful for abstracting away from details, and for differentiating and correlating structures of models and their usages. Since there are well-known basic data structures, algorithms and software libraries related to matrices, their use may foster calculations with FA. Setting up this framework can make it possible to communicate and utilize different descriptive models, transparently or independently of the tool used to build them and without sacrificing the definitions of models.

Msin F ← -Msc I - → Set (
One question not addressed in this paper is the way in which models change and evolve over time. This aspect might be manageable canonically using the structure of models. It would be possible to include within a structure an 'off' object, the 'black hole' (to model a destroyed box) yielding a new structure K. A functor from a category K t at time t to the same category K t at time t > t could then be defined. By taking the time instants as objects in a category T featuring some order, and defining a functor from T to K, we would then be in a position to address change and evolution in models with the structure K [START_REF] Andrée | Hierarchical Evolutive Systems: A mathematical model for complex systems[END_REF].

The matrices A and B corresponding to the functions f A and f B are as follows. shows in practice that there is also a link (w 1 w 5 ) coming from e and supplying a. Typically, a port will be either an input or output port of a box.

Figure 1 : 2 Figure 2 :

 122 Figure 1: A box Y composed of 2 boxes X 1 and X 2 Figure 2: A box Y composed of X 1 ⊗ X 2

Figure 3 :

 3 Figure 3: A box Z composed of X

Figure 4 :

 4 Figure 4: From left to right: a box X, an invalid-box X and an arrow X → X

Figure 5 :

 5 Figure 5: A box Z composed of Y , itself composed of X

θ 1 -θ •θ 1 -

 11 → Y and Y θ -→ Z) from the port h of Y to its port f , vanishes in Figure3(the arrow X -→ Z) resulting from the composition. There are two reasons for this: the port f is not connected in X θ 1

Figure 6 :

 6 Figure6: X 1 , X 2 , X 3 , X 4 → Y

  matrix A means in practice that there is a link or wire (w 1 ) coming from the port c and supplying the port a. There are also two links (w 2 and w 3 ) coming from c and supplying b. The product A × B given byA × B = e f a {w 1 w 5 } / 0 b {w 2 w 5 , w 3 w 5 } / 0

http://ieeexplore.ieee.org/document/6129467/

https://www.fmi-standard.org/

* This work was carried out and funded in the framework of the Labex MS2T. It was supported by the French Government, through the program "Investments for the future" managed by the National Agency for Research (Reference ANR-11-IDEX-0004-02). This work was co-funded by the Airbus Defence and Space company.

Appendix

Connection between morphisms of Mscm of and certain matrices over a semiring

The connection assumed in Definition 3.1 is established and proved in three steps as follows. [START_REF] Blochwitz | Functional mockup interface 2.0: The standard for tool independent exchange of simulation models[END_REF] an equivalence between certain functions and matrices over a semiring is proved. Then (2) certain functions are shown to be equivalent to the morphisms of Mscm, by rewriting the signatures of morphisms' component functions ( f in and f out ). Finally, it is deduced (3) that a morphism of Mscm yields a matrix being one of these certain matrices and the converse. Computations relating to morphisms are then made via matrices. Finally, matrix multiplication is used to obtain the composition formula of Mscm.

Let K be the power set of the set of strings of finite lengths. (K, ∪, •, / 0, {ε}) is a semiring [START_REF] Droste | Semirings and Formal Power Series[END_REF] where × := • is the product induced by the string concatenation operator, + := ∪ is the addition given by union of sets of strings of finite lengths, 0 := / 0 is the zero given by the empty set, and 1 := {ε} is the unit given by the singleton set containing the empty string. Let also I and J be the finite sets with n and m elements respectively.

Proof of (1). Let f : I × J → K be a function. Then M(n, m) is a matrix, given by M = a i j , a i j ∈ K, i = 1..n, j = 1..m. Conversely, given a matrix M = a i j , a i j ∈ K, i = 1..n, j = 1..m, the corresponding function is f : I × J → K given by (i, j) → a i j . This completes the proof of (1).

Proof of [START_REF] Bruni | Hierarchical Models for Service-Oriented Systems[END_REF]. The data (1) of an arrow can be rewritten as follows. We define two functions f out , f in

where Y in = in(b), Y out = out(b), Z in = in(a) and Z out = out(a). 2 L is the power set. Like the functions θ in and θ out that are total functions, f out and f in are also total functions given by associating with each element α of their domain the set of elements that are each the preimage of α in θ in and θ out respectively. From (1), we have 2 L in , 2 L out ⊂ K. Hence, the functions θ in and θ out are equivalent via ( f out and f in ) to certain functions f : I × J → K. This proves (2).

Proof of (3).