Dominique Blouin’s Presentation on MBSE and Systems of Systems for Télécom Paris.
Dominique Blouin, an expert in the field of systems engineering, on March 22, 2024 gave a presentation at École polytechnique discussing the Model-Based Systems Engineering (MBSE) approach and its application to Systems of Systems (SoS).
In her talk, Dominique Blouin highlighted the benefits and challenges of implementing MBSE for SoS and provided insights into best practices for successful adoption.
To explain to you a little how this will happen, we have built this day a bit like what the chair is supposed to be, that is to say a meeting place between industrialists, academics and then the defense environment since, once again, if you are not quite accustomed to the chair Complex Systems Architecture it is a chair which starts with four industrialists who come to meet the Polytechnic Institute of Paris , you have them directly here, they are present in the room and we will be able to chat with them throughout the day; four industrialists who come to see the Polytechnic Institute of Paris to set up a teaching and research chair. So the chair is in the emerging phase since we will have the opportunity to talk about it again but, currently the four schools which are directly concerned by this chair, which are École Polytechnique, École Nationale Supérieure de Techniques Avancées , Télécom Paris and Télécom Sudparis and they are in the recruitment phase; so there are recruitments underway for four teacher-researchers who will be dedicated directly to the work of the chair. While waiting for this recruitment, this day, we wanted to build it a bit like a project life cycle, that is to say that this morning, we will already have two first presentations, with a first which will be the presentation of Télécom Paris and then this will give rise to a certain number of exchanges, questions and answers in any case we hope; a second intervention then which will be the intervention of ENSTA Paris, then same thing: presentation and then Q&R and then after a break we will move on to a first workshop. You have seen that there are a lot of red chairs lined up there, on the platform, and they are intended to welcome representatives of patrons, of the Defense Innovation Agency, of the General Directorate of Armament – you recognized a few costumes earlier during the welcome – and then the representatives of the four schools and there we built it like a workshop where each participant will have the opportunity to directly present a problem, present an area of work and directly initiate a dialogue; and then as obviously we are on standby since the entire day is broadcast in the form of a webinar and we will check; if we have questions that are directly in the room of course we have enough microphone for that and then I hope that this will once again allow us to refine, to directly relaunch the exchanges… so that’s how we built this day in a morning squall and an afternoon squall which are almost identical; and so as I told you, we are going to start our morning with the presentation of Télécom Paris. I will therefore quickly give the floor to Dominique Blouin; then Dominique Blouin he is associate professor at Télécom Paris; Dominique Blouin is a member of ACES (Autonomous and Critical Embedded Systems Research Group within the LTCI (Information Processing and Communications Laboratory) Among Dominique’s preferred areas is multiparadigm modeling, I think that this may speak to some or some of you… MPM is a modeling which recommends the combination of reusable modular modeling languages rather than the use of a single monolithic language for the modeling of the entire system, Dominique it’s up to you. Hello everyone, thank you for giving me the chance to present different research work in this chair, it is a chair that interests me a lot in fact because as you will see we work a lot on it. Architecture, the modelisation of architectures and with systems which are more and more complex and/or complicated today and so I first planned to give you a perhaps, in fact to remind you a little or to discuss a bit of what a complex system ultimately is, what architecture is very briefly, what MBSE is, model base system engineering, is. There are a lot of industrialists here I think so, how many of them practice MBSE in their industry? Can you raise your hand ? Okay we’re going to talk a little about that, I’m always interested in knowing how it’s practiced in the industry, because we ‘re academics and sometimes we don’t always have the right information, we’re going to see that all in time and then I’m going to talk to you really more precisely about my research, it’s what is called Model Management. In fact we realize that when we create complex systems, we model but we don’t just have a single model, we have lots and lots of models to be able to cover the different aspects of the system, the different levels of abstraction and therefore we have to be able to manage these models, otherwise we will see in fact that we have a lot of problems in our designs. That’s it after a short conclusion… So what is a complex system? I took certain images here, there is perhaps a small distinction to be made when we talk about a complex system; If I talk about complex systems to my colleague Ada Diaconescu she will tell me : "but no, it’s not complex systems you’re working on, it’s complicated systems !" So what is the difference between the two? So I went to look a little on Wikipedia to see what we say about a complex system, what is it? We actually say that it’s made up of several components that interact with each other, but I think that’s not enough. Already this applies to different areas as illustrated by the figures here, the areas of transport, planes, boats, here it is the Falcon Maltaise, it is a completely automated boat which can be sail alone with the sails and so on, which almost doesn’t need anybody to sail, that’s why I put it there, power grids, connected cars and we’re even talking about a complex system of living organisms such as the human brain, human organisms and even the entire universe! So that covers when we talk about complex systems, it covers quite a wide range, I’m not sure in fact that in this chair we want to talk about the universe or the brain or all that but hey it’s still good to recall a little what it is, but one characteristic above all of these systems, which interests me, is the difficulty of planning what these systems are going to do, that is to say the difficulty of planning everything at the design, to know exactly what the conditions will be in which these systems will run in fact to plan everything. That’s what I think is a bit of the complexity here, we see things as non-linearities, spontaneous emergences, emergent properties which are in fact perhaps a little more than the sum of the properties of compound systems, so this is in fact also where design becomes difficult and this is where it is also important to talk about architecture. Talking about complexity in my field, in fact, we, at Télécom, work a lot on a modeling language called AADL, I don’t know if you know it, it’s an embedded system modeling language, we’re part of the committee of standardization and therefore it is a language which was originally for avionics, so we often use this little graph here to show the complexity of the systems, the evolution of the complexity of systems in avionics. And here what I simply have is for the two major aircraft manufacturers Boeing and Airbus, we have graphed the number of lines of code, SLOC is Software Lines Of Code, so we use that a bit as an indicator of complexity because in fact in avionics we realize that an airplane must implement more and more functions, there are lots of things that are automated, the pilots, the landing et cetera and this actually results in a strong growth in the number of lines of code and so if you have a logarithmic scale and when we draw up the graph, we realize that the number of lines of code doubles every 4 years! So here we are in a bit of non-linear effects if we see. So in fact what is happening is that we are really having problems developing these systems. So in this graph here, you see, it’s an old graph here you are in 2010, you see that at a given moment if we continue the line we would see that we still arrived at 299 million lines of code but in fact the latest projects that took place in the United States, the last helicopters that were built, people realized that in fact they arrived at this curve. They had specifications full of functions that they would have liked to implement for their helicopter but in fact, due to the complexity of these systems and the difficulty of developing them, they were forced to reduce the specifications because that it would have cost way too much! It wouldn’t have made sense to build such an expensive helicopter! So all this to show the complexity problems that we have in avionics and I think that it’s not just in avionics. If we talk about the car, it’s actually just as complicated now as a car, then when we talk about a connected car it’s even worse! I like to show here this little graph which comes to us from our colleagues in the US we look at the F16 and the F35 so they have done quite a few studies on this on the development costs of the F16 and the F35. If we look at the number of lines of code we realize that the F35 has 175 times more lines of code than the F16 so it’s still quite a bit more! Quite a bit more complicated, quite a bit more function and if we look at the effort that was required to develop this plane, in fact it’s 300 times more and so we see that we are once again in non-linearity problems, all due to the complexity of these systems. And then if we look at the European counterpart we will see the A400M, in fact 10 years of delivery delays, it cost much more than expected we can look at the EPR, there are plenty of examples in fact which illustrates this complexity. Now what is architecture? Well I think you all know more about what system architecture is here but I went to look at the Wikipedia definition once again, it’s basically a conceptual model which defines the structure and behavior of the system and also which defines views that we can have on this system, views which capture properties of interest and which are very often linked to what we call the stakeholders of the project. So typically we have architectures which are based on components which are hierarchical, a component is broken down into sub-components and what is needed is to make all these components work correctly, together, so that the system overall works. correctly. In modeling we are going to talk about architecture description language, AADL is one but there are obviously several, there is SysML which you know. There is a standard for the description of architectures, IEEE 42010, which provides us with a bit of a metamodel of what architecture is, the system of interest to an architecture, we use a description of these architectures. , we have stakeholders who have concerns, we will therefore, for these concerns, we will create points of view on the models for these concerns which will govern the way in which we create the views et cetera. So that’s something that’s still very interesting, it’s still the basis of a lot of architectural description language. Now what is complex systems architecture? Well we’re going to combine a little architecture here with these different complex systems that we can find, so obviously we’re not going to be interested in the architecture of the universe I think, that’s not the goal of the chair… And now what is systems engineering ? INCOSE you need to know all that, it’s the international Council of system engineering, so in fact it’s a transdisciplinary approach to developing systems but which concerns all phases of the system life cycle at the same time , both from its design, from its use and after that the systems, now as we see in the cycle here well they evolve, so it’s not because we have a system that works, we have maintenance, but eventually the specifications may change, the user needs will change, so we will see developments, transitions and so on, so system engineering is very good because it specifies all these processes and how we must develop these systems. And now what is model based system engineering? Well the idea is that we are going to do system engineering but not only with Word documents and Excel documents but we are going to use what we call models . So that’s a bit of what we call a paradigm shift that started a little while ago. We have been working on AADL for at least fifteen years. Is AADL used a lot in the industry? It is a bit, the American army actually uses it now in production but it hasn’t been that long. So it’s a paradigm that has existed for a long time but it took a long time before it was adopted by the industry, that’s why we’re going to take a look at the state of the art. But the main idea is that instead of specifying our system with Word documents, informal architectural diagrams, boxes and arrows drawn with Powerpoint, we will build the right modeling languages that are good for specifying this system and one of the very first advantages already, it is how it allows us to agree on a vocabulary. When we work in these fields, we sometimes realize that even two experts in the same field can have slightly different meanings on certain concepts. So what we are going to do is that we can use for example antologies to precisely specify the vocabularies so in our language AADL, when we say a processor we are not saying something, everyone is standardized, look in the standard and we know what that means. Already, the fact of building a modeling language allows us to agree on the terms and then when we use a modeling language to specify a system we are obliged to be more precise, we are less expressive, we cannot say anything like in natural language because we are limited by the concepts of the domain, but as a result, we are more precise and often it is easier to arrive at a correct specification. What we already did as part of my doctoral thesis, we took a Best Practice guide from the FAA in the United States for requirements engineering which gave an example of a small system: an Isolette , a children’s incubator in a hospital and he gave a whole set of requirements and use scenarios for that in natural language and we said: hey, we’re going to take AADL, we’re going to take a language modeling of scenarios are not the use cases of UML but they are something else, we are going to model everything. And so, although this is a document recommended by the FAA, we found a good dozen errors and inconsistencies in the scenarios. All this because we had a tool to specify the scenarios and on top of that we had a simulator which allowed us to see the execution of the scenarios and thanks to that, we were already able to find these errors. So the more we find these errors from the beginning, therefore the more we model, the less chance we have of having errors at the very end and finding them when it is too late, that is to say when we have already developed the system. And in addition, obviously, modeling languages allow us to develop tools that will help us, who will carry out checks on our models to detect design errors and inconsistencies as early as possible. In the United States they have already done quite a few studies on this with the AADL language. In fact they had a program called SAVI system architecture virtual integration and they really felt that it could be the return on investment of these processes. And they came to the conclusion that there was at least a 25% cost reduction, and that’s really a pretty conservative estimate. These are things that they did at the SII and so the idea is that we want to model instead of program, those who know programming also surely know this compilation chain. At the beginning, when I started my first programs, we worked in assembler… Well, programming in assembler was a little complicated… As soon as we had to do something a little complicated it was really difficult and so people have the idea, the excellent idea of developing what we call programming languages at a higher level of abstraction, that is to say of having constructions in the language which are directly, which go directly with what we want to do, as programmers. And so with our string here, we convert that into an intermediate language, for each language we will have a converter and in the end we will convert that into binary code for the right processor that interests us. And so that significantly improved production. What are we trying to do in model-driven engineering, well in fact we’re trying to go even further back in abstraction. So here you see I put something called the MDA process model of V architecture of the OMG, so not only do we go up in abstraction but also we try to separate the concerns, have different models for different concerns and we are going to combine these models. So here we are more at the level of requirements, needs, then we will have a model of the software platform, the hardware execution platform and then we will combine that to have a real model that could be executed. And this is where we are already going to do a lot of analysis simply based on the models, without even having implemented anything, and this is where it pays off too, as soon as we find problems, we go back to the right place, maybe there may be errors in the requirements, we can come back to that, we iterate, we iterate and when we have a correct model according to our analyzes and then we come back to the old compilation chain, we generate the code and we generate the binary code automatically. So we at Télécom, we work quite a bit on this, we have a tool which takes AADL models and which generates C code automatically for different given operating system platforms. Now the state of the art on MBSE practices so we saw that there are a few people here who probably know more than me on this but I did a quick search – I didn’t get time to do an in-depth research – I found this article there, I don’t know if any of you know it, it is actually referenced on the INCOSE website: State of the art of MBSE practice, it’s still quite old, it dates from 2019, so before COVID, but I honestly haven’t found a more recent one and so it has some conclusions, which is good, but apparently , indeed those who apply "model based" approaches really notice an improvement in the quality of systems and in efficiency, when we practice the classic tasks of model-based system engineering , greater ease of communication between engineers and they actually concluded that the processes, the methods, the notations are still quite mature and effective for systems engineering tasks so do you, those who practice, agree with that? Yes ? Is it realistic? Okay, that’s good to know! On the other hand, he identifies a certain number of problems which prevent the adoption of the MBSE because it is far from being completely widespread… Cultural problem, I think you all know a little what it is: we are engineers, we don’t want to change the way we work, we know that our way of working works, it works, we don’t want to take the risk of blowing everything up – as they say in France – and so that’s a big problem. Several people will still tell us today: "Ah! the MBSE is useless, it’s useless, it’s complicated, it doesn’t work", so here too it’s these beliefs that are there! You also need to learn new…skills, how do you say it in French? New skills – excuse me – sometimes new skills, so it changes us a little, we have to change the way we work. We can also say that the tools, learning is not always easy, I don’t know if you have already used Papyus for SysML? I give a UML course with my students, I make them use Papyus and it could still be better… We use it because it’s free but there is still a little step before we can use it. ‘to use. And so that’s a problem and here also the Act of Management Support and we have done a lot of research and that’s what I’m going to talk to you about the challenges, the challenges that we have in the MBSE . So there are several approaches for the MBSE, there is something called Arcadia you should perhaps know the Arcadia method, it is widely used at Thales, it was Jean-Luc Voirin who created that and there is a whole suite of Capella tools which is a language in itself and which is largely inspired by UML and SysML but it is not UML and it is not SysML. So in fact, Thales has somewhat redone their own approach, their own methods, their own tools to make MBSE. But it works and it’s actually very popular and there are regular webinars on Capella organized by OBO and sometimes there are up to 300 people participating in these webinars. In relation to that, at the AADL committee, when we are 40 people we are happy. Another CESAM process that I know less well but I know that it exists, we had projects with Safran Electronics and Defense, they are more into these approaches. As we work with the Americans, we talk a lot about ACVIP Architecture Centric Virtual Integration Process and that’s what they are currently implementing in the American army to build their new programs such as the future Vertical Lift. They use SysML a lot and obviously AADL. Afterwards I’m going to tell you a little about PST, it’s a project that we did with IRT Systemx and ALSTOM and SAFRAN also in which we also tested a system engineering approach by combining several languages. I’m going to talk to you about this a little quickly so ACVIP is their main diagram in the US, you all must know, I think, the V cycle, it’s classic, so in critical systems, we are still on V-cycle process, we are not really in AGILE where the central element is the code, we are not at all there in a complex system, so you have the engineering phase of the requirements, system design, software design, component design, the code, and on each side, in each phase, you already plan, from the beginning, a corresponding verification activity. And so what they do is we talk about virtual integration, that is to say we will add a second V in parallel to the standard V and at each stage of the process we will use models to represent the specifications and from now on, here, we will do some verifications. We won’t wait until we have built the system to do our tests, we will do lots of checks and that is very effective! For what ? Because in fact, there have been quite a few studies that have been done which have shown that where do errors come from when we develop systems? Me I remember I was a developer in the industry for a long time, we often talked about Bug Analysis! We told ourselves that in the end it was not always us the developers who made the errors, sometimes the errors were much higher up in the one who had done an analysis. There were problems and as a result it had impacts all along the development chain which was still quite significant. And so, in fact, we realize that we can have lots of errors that arrive during requirements engineering. In an airplane you have thousands of requirements captured often with a tool called Doors and if you can only inspect that manually then you can easily have two conflicting requirements in your specification. What happens if I have two conflicting requirements? Well that means that there is no system that will satisfy all my requirements… So I’m already stuck. From the requirements we can do a lot of work here and that’s why it has a whole community, that there is a conference called Requirement Engineering where there are lots of people who work on lots of interesting approaches to try to improve the quality of requirements so 70% of errors and 80% of errors found only here! So obviously it’s expensive and we have to go back and rebuild the system. So the idea is to discover the errors, we are "architecture centric" centered on the architecture so really the main element is the architectural model but around that we will have lots of other models precisely which will be used to do lots of analyzes to verify our design. If we want to check concurrent access we can very well convert the architectural model into a Petri net or whatever we want to do our analyses. Okay so that’s what they use a lot in the US. As part of the IRT Systemx PST project in which we are involved, PST stands for Performance of Transport Systems, we worked a lot with Françoise Scaron if anyone knows her from Iris Conseil and so we have implemented rather a process that really comes more from it than anything else and the idea here is to actually use the requirements in a ReqIF format because it’s an interchange format that’s easy to convert, but we could also have had the requirements in SysML and then we have the system model and the idea is that we have the system model which is used, in fact, to manage all the constraints of the system. between the different domain teams of the system. So you will be able to have the system engineers who will oversee the design, they will say: you, the embedded systems, you have this constraint because if you do not respect this constraint it will cause a problem for my mechanical engineers or my design engineers. another area. So here in this approach, we really have the system which serves to govern the constraints a little, to distribute the constraints between the different specialties. And so we tested that but we only did one specialty so although we are far from having something perfect and the specialty we had was the embedded system part. We had a case study which was the railway with Alstom, we tested a bit of a kind of braking system with a "Two among Three" approach so with redundancy for the critical systems and we used AADL and Alisa, so there’s something called Alisa that people don’t know well in AADL which stands for Architecture-Led Incremental System Assurance where we can actually capture all the requirements that we have for our system and not only can we capture but we can obviously link them to the architectural model but in addition express our requirements in the form of constraints with a constraint language dedicated to AADL called Resolute and when that is not enough, we can also define a plan verification in this environment, a set of verification activities verification that must be performed to verify our requirements. So typically it can be launching an external tool which will do calculations and which will put back into the architectural model revalorize properties it is the energy consumption, whatever, and then we will have requirements which will test values: the energy consumption must not be greater than this or that value. We can also encode design rules, say "I must have all my processors of the same brand" or of the same category. We can encode all of that. So we used that as a verification environment and it worked well. We were one of the first to use this environment so intensively, which made it possible to identify a lot of errors and to do a lot of back and forth with the SEI to correct the problems. But I’m showing you this mainly because in a process like this, somewhat realistic, we actually see that we have lots of models and in fact there is lots of information that is common to these models. I have my SysML model of the system, in AADL I have a bit of the same thing, I have a bit of the same components but I will perhaps go into more detail on the embedded system parts and so what is it what we did to manage that, well we used a tool in the Eclipse platform called Capra; It is a traceability tool that allows you to trace any model, model element with any other and create your own traceability metamodel. And so we used that, we created an extension for AADL and so on. But all that does, it just makes traces and if one day I delete an element in AADL, we had for example the ReqIF requirements and well we have some of the same in Alisa. So if I delete a requirement there it will just warn me: “be careful there is an inconsistency” but it will do nothing more for me. So clearly, it’s to show that it’s perhaps not enough when we have thousands of models like that we perhaps still need a little more automation there. Very recently we had another project called ARCHEOCS with the IRT Saint-Exupéry. The goal of the project was to do multi-CPU on distributed platforms for synchronous applications and so we worked once again on the process part. In this approach , we have defined a process which actually implements a chain of tools called Asterios which you may already know. We had a case study which was a braking system once again but a braking system for avionics, so it looks simple but in fact when we look at the model of this braking system, there there is lots of lots of lots of components and it’s not at all an easy case study. And there, we made the choice to really formally represent the process with a language given for that and so we used a language which is developed by our partners and colleagues in Belgium, it’s called FTG+PM it’s Formalism Transformation Graph + Process Model. So here what do I have? I simply have a set of modeling languages and I’m going to define how I can transform a model from one language to another with a transformation. So I have a sort of language dictionary and a dictionary of my transformations between these languages. And after that, I’m going to want to model my process and I’m going to have the process model and in fact it’s simply a UML activity diagram for those who know it but specialized for modeling in the sense that, here, I’m going to have activities which will only take models as parameters. In fact it’s a view where all models, we also call it the Model Verse, it’s another way of talking about it. So here I’m going to combine each activity in fact, it’s going to be typed by a transformation, here each model is typed by a language, so I’m going to represent that and so I can use that to try to guide my engineers to see if they follow the process and tell them what is the next step knowing that we are modeling not only activities that are automated but also manual activities, we will both represent them here. And so we used that for a real case study, a process for distributed multicore planning with Safran in Massy and you can see the kind of diagram that that gives us… In fact we realize when we look at things in detail – in English we often say "the devil is in the details" – in fact it’s more complicated than we thought. You see here, this is the overall process, so here we have the activity diagram typed by each language implemented and each transformation implemented. So that’s the overall thing, if we go into the detail of when we do the analysis and distribution for the network and so on, the synchronous applications have yet another diagram that is still quite complicated. So the goal was to test these approaches a little with a real case study and this is where we actually integrate the Asterios tool chain and when we see that, we see that it remains still a lot of problems there because our transformations, in fact we are not very precise on what a transformation is in there. We simply say "I can transform one model into another" but in reality we need much more than that and this is where we arrive at the challenges we have in model management. We have lots of models and we have to manage them. So the first challenges we have are "how to manage so many models correctly" and one of the problems that is important here is the consistency of these models. So it’s mainly that we are in development teams now which are delocalized: engineers from different fields work in parallel, make modifications to their models but each of these models talks about the same system so they necessarily have information in common. So if I make a decision to change that… That’s why we have the systems engineer who will oversee all these decisions but we would like to have a little automation. How to specify processes? There are lots of processes in the industry but very often it is documented in Word, there is no modeling language. Another thing is how to combine languages? Very often we will do co-simulation. I have a simulator for a language, I have a part which represents a part of my system, I have a simulator for another part of my system, well I would like to reuse them so I am going to integrate them together to be able to simulate the entire system. How to do this? This is a whole area of research and it is also part of multi-paradigm modeling. The importance of model consistency I will take an example that you may know, the Airbus A380. You remember this problem. It’s a bit old now and it still cost a lot of money. So you had the cabin developed in Toulouse, the models are made with CAD tools, I don’t know which one, and you had the cables modeled in Hamburg in Germany. We make the models and everything is going well but already, apparently the engineers when they started working together, there were not only tooling problems but even cultural problems, apparently from the start, the French had difficulty in speak English and the Germans had difficulty speaking English… Already understanding each other was complicated. But here, what happened was that they used the same tools for the CAD, but with different versions and because of that, there was an inconsistency that crept in between these models. So the relationship of coherence between these two models was broken and when they came to integrate the real system, they came to put the wires in the cabin, well a few centimeters were missing… So that delayed the program. several years, it cost very, very expensive… So that is the case of the Airbus A380. But it happened also in many other cases; we see them regularly; for example I remember we saw on the news that the SNCF had ordered new trains… Ah! there are stations that are not wide enough… So the idea in fact is really that if we manage to model all these specifications well maybe I can have tools: I order trains and well I can have a tool that will check among all my models… Is the width correct or not? And the same, here, we will have to have the integration of the models to show that we must manage the models well, it is important. And so it’s an important area to the point that many companies are starting to be interested in it. There is Dassault Systèmes… I attended a Dassault Systèmes tutorial in Montreal, at the models conference where we showed that they actually manage to connect a requirement in a requirements language to a part of a Catia model, all this to really ensure that you manage these models well. They also use Magic Draw I believe, Magic Draw for SysML and they are really building an integrated approach where we try to link all these tools. I think they are a partner with a company called SYNDEIA or, in fact, they do a bit of the same thing. There is an open source project where we are also trying to develop a Model Management system. ANSYS has something called Model Center, there is a GPL project in the United States called Open SESAR where we have developed a specific ontology language: Ontology Modeling Language and we try to federate all the models in a single ontology language. So there are plenty of approaches but what happens is that everyone works a little in their own corner on this and there are no real foundations that are studied. This is what we academics try to do: develop foundations. I don’t know if I’m taking too long… Maybe we’ll shorten it… So we have an approach here called AcMoM which is a project that was funded by the DOD, we created a first infrastructure is with something called Mega Models, well I do n’t really explain what it is but, basically, it’s modeling modeling, in fact, the FTG that I showed just now it’s a Mega model. So we’re going to go over this quite quickly but the idea is that we also trace links between different model elements and we can define operations on each of these links, which means that when there is something which changes, we execute an operation to maintain consistency. So this is the work we do. We are now working with another partner from Brest who has a tool called OpenFlexo, this is really model federation and the approach is a little different, in the sense that we are going to create a new meta model , a new set of concepts that will read and write data into the base models of the tools in fact. So it’s an approach that is not disruptive. So we started to compare that… We are also part of another ANR project called CAOTIC where we have, once again, to build a tool chain so why not use Model Management to build this chain tool there… So here I have two tools that do worst case execution time analysis but they take the data in different formats and how do I manage that? Well, we in AcMoM generate relationships between these different elements with an operation which will link the data of the two and which can be executed if we change the data to maintain consistency. Here in OpenFlexo we have a different approach in the sense that we really have a new meta model which represents all that and the interest of that, in fact, it is the approach that we ultimately chose because we want that our users do not have to know each of the tool formats. So we have a central model, users only have to learn this central model and everything is done via this tool, and everything remains well synchronized. We also created a small workflow language that allows us to run these different tools through OpenFlexo. So, just to show you what we do. Co-simulation I might not talk about it because we don’t have time. A final challenge is the validity of models, often the model is a representation of reality, so a model is based on hypotheses, a model is never perfect and we have a thesis precisely where we work to represent this formally. I am a simulation model, I formally represent my simulation hypotheses but I also represent the precision of my model, which means that if I am at a precise stage of my design, I know what tolerance I need and I can better select the model I need. So this is a small example to show that models are based on hypotheses with simple physics. Here it works with notions that we call frames, so when we develop the model on this side we have what we call experimental fram because we do an experiment to capture the model but we go to the time to know the context of this experience to better capture then, when I am going to use my model, under what conditions it will be usable or not. And by chance, we were later contacted by Renault who had precisely this problem. There is the Renault group in Guyancourt and they are specialists in modeling. They have lots of models and they have problems to manage, to choose the right model for what they want to do, there are so many models. They have already started working on the subject and they have a concept called Model Identity Card and the funny thing is that they actually use SysML to represent simulation models. And so we are working with them on a new approach which will undoubtedly rely on our other thesis on validity to improve these things. So the systems are more and more complex, all this to say that we need Model Management not only at Design Time… So in fact the reality is that in real complex systems it is very difficult to plan everything from the start, and therefore we will be obliged to have what we call self adaptation to try to configure the system automatically and we arrive at an area which is increasingly popular: Digital Twins… What is a digital twin? in fact it is a model of the system in operation and as a result we are going to rely once again on lots of models… It may very well happen that the environment changes… The system changes as a result and we are forced to change the model and therefore we must know under what conditions the model is valid or not and therefore we also need a Run Time management model. Well, SysML V2 I will talk about it later and we will conclude… So we talked a little about what complex or complicated systems are, the architecture, MBSE, common approaches in MBSE and we we talked instead about the challenges on Model Management, consistency but also validity and another subject on which we want to work is changes, how to manage "who can change which model" We often have a notion that we call Authoritative Source of Truth means that I have several models that contain the same information, if I have an inconsistency, which model has the truth? So we also want to capture this formally to better manage our consistency. We have a thesis in this area. We had the news yesterday that the first workshop on Model Management was accepted at the models conference, so if you work in these areas and want to publish articles you will be welcome to submit, the conference will take place at Linz in Austria. So here is !