 And the recording has just started. Well, thank you for the introduction, Thomas. So we're here for the second of three presentations with the general theme of model basis and engineering demystified. In this one, I'm going to talk about a topic called MBSC and slide. So this is what I usually look like. All I can say is never enter into a bet with a German when your personal dignity is at stake. So for those of you that were here for the first one, just a very brief recap. And one of the main points that we made during the first presentation was this major difference between model based systems engineering or this I should say this perceived difference between model based systems engineering and systems engineering. And one of the main points that I made was that model based systems engineering is a natural evolution of traditional systems engineering or what we were referring to as document based systems engineering. And one of the things that we're trying to do with this series of three presentations is to dispel some of the misconceptions and some of the myths associated with model based systems engineering. And one of the main ones is model based systems engineering is not a separate discipline of systems engineering. It is systems engineering. And if we're going to be quite quite arrogant about it, it's about doing systems engineering properly. It's doing it with a leg of rigor. And what we spoke about in the first presentation is why this is. And one of the things that we saw is that over the last few years of the last few decades, that the complexity of the systems that were involved with developing was increasing dramatically over over time. And one of the main points then was that if the systems that we're developing are becoming more complex, then so the techniques and the practices that we that we apply to develop these systems must also evolve to reflect this increased complexity. And what we saw is that there was indeed rather than the step change between a document based approach to systems engineering and the model based approach to systems engineering. We can imagine that there were these conceptual stages between them when we went from document based systems engineering to document centric systems engineering to model enhance through model centric up to true model based systems engineering on the right hand side. And one of the points that we were making is that not everybody wants to get to stage five and there are these different stages in between. So what I want to talk about today is to take this a step further to talk about exactly what do we mean by model based systems engineering and what are the main aspects that we need to consider in order to deploy model based systems engineering successfully. So we do this using a thing called model based systems engineering in the slide. Now before we go any further, I will point out there is going to be more on this slide than just the word system. This would be tremendously disappointing if this was the ultimate slide. But this is the start point for any of us as systems engineering. And the reason why I have system by itself on the slide is because what we must remember is that our job is to develop the system. Our job is to realise this system successfully. And in order to do that, we're going to be applying systems engineering. Now when we talk about model based systems engineering, the goal of model based systems engineering is to realise this system successfully. The goal of model based systems engineering is not in itself to generate a model. Our goal is to generate the system. This sounds obvious, but it's important that we can state the obvious occasionally because it's very easy for people to forget what it is we're trying to do in the first place. And particularly when people are using new techniques such as visual modelling. So if they're using, say, system L and they're using modelling tools and so on, it's very easy for people to forget what the point of the modelling is and just to go off down a rabbit hole or to go off to become too focused and go into too much detail and to forget what it is we're trying to achieve in the first place. So this is one of the main things that we need to remember is that our job is to develop the system and we're applying model based systems engineering in exactly the same way we would be applying systems engineering because model based systems engineering is systems engineering. Now the main difference in my in my mind between a traditional document based approach to systems engineering and a model based approach is that of the information and the knowledge and the data that we have concerning the system. Now in a traditional approach to systems engineering, all of this information, all of this knowledge and all of this data is owned by and lives in a disparate set of documents or a set of documents that spread across a server or multiple server. And in reality, on a real complex project, we can have hundreds if not thousands of these documents and all of the information is spread across this set of documentation. This becomes difficult for for many reasons or one of the main reasons is simply in terms of maintenance. How and after we ensure that all of these documents are consistent with each other that we can maintain this consistency with each other, particularly when we start to make changes to one document. How do we know that this is accurately reflected into all of the other documents? Now, I would also qualify that by when I said all of the information is contained in the documents. We also have to bear in mind that some of the information isn't contained in the document, it will be contained inside people's heads. It will be what we refer to as tacit information. So it's information that isn't formally captured anywhere, but it's just actually lives inside people's heads. And it's never actually formally documented in any way. When we have a model based approach to systems engineering, we have this idea of a model. And when we talk about a model, you will often hear this referred to as a single point of reference or a single source of truth. And what we mean by that is if we want to know anything about our system, if we want to know any information about our system, we interrogate the single source of truth, we interrogate this model with a document based approach to systems engineering, we go and look to the documents with a model based approach to systems engineering, we actually look to the model because that contains all of the information in a consistent fashion. So that's where we'll get our answers from. Now, at this point, when you start to talk about a model based approach to systems engineering and a model, people will say, well, they will usually, it will usually be a misquote or a misunderstanding of a paper by God called box for many years ago, and they'll say, all models are wrong, some are more useful than others. People that say this, and without understanding it properly, just don't get it basically. What you have to bear in mind is that one of the big arguments about models is it's a big overhead and you spend all your time putting all of your information into the model. If the goal of the model was to contain all of the information concerned in the system, that would be true, but it isn't. The goal of the model is not to contain as much information as possible concerning the system is to contain enough information as necessary to allow me to realize the system successfully. And that's a subtle difference, the difference between as much information as possible and as much information as necessary, but it's a very, very important difference. So the model should not contain any information that isn't directly contributing to realizing my system. This is a very important distinction to make. This is the difference between just having an endless task at your hand, which is just putting more and more information into the model and actually focusing that information to making sure that it contributes towards realizing your system successfully, or to put it another way to making sure that all of the information that's contained in the model contributes in some way. It adds value. It's adding benefit to what it is we're doing in the first place. So this is this idea of a model. A model is an abstraction and what we mean by that is a simplified representation of our system or our systems. The basic unit of a model is what we refer to as a view. A view in its simplest form you can think of as a collection of information. That's the simplest way to imagine a view. However, we've just said that only relevant information, only necessary information can be contained within our model. So we need to ensure that the information contained in each view, or to put it another way, each view is adding value to what we're doing. And the way that we do that is we need to capture a couple of pieces of information. And there's two things that we need to know. First of all, we need to know, sorry, let me get my pen. I'm going to turn it to my pen. Right, I need to get my pen drawing again, but in the meantime I'll talk about, I'll just talk on what we need to understand is who. And whenever we say who in systems engineering, what we actually mean is which stakeholders. And we also need to understand why. And when we say why, what we really mean is what's the value or what's the benefit of doing that. Okay, let me try that again. So you'll be sick of me saying this by now. So we ask ourselves two questions. We ask ourselves who. And when we say who, what we mean is which stakeholders. We ask ourselves why. And when we say why, what we mean is what the benefits basically. And if we can't answer either one of those questions, then it's quite simple. It's not a valid view, but we don't do it. Okay, and this sounds quite harsh, but we need to be very rigorous about this. We need to be very, very harsh about this because we can't have information in our model that isn't directly contributing to realizing our system successfully. So we ask ourselves both who, so which stakeholders, and why, what are the benefits, essentially. If you imagine that the model is like a big ball of, sorry, PowerPoint's just failed again. If you imagine that the model is like a big ball of information, you can imagine that the, hang on, PowerPoint's just failed. Draw and finance, see what happens. So we ask ourselves two questions about this, who, by which we mean which stakeholders, and why, by which we mean what are the benefits. If you can imagine that the model is like a big ball of information, each view is like opening up a small window into that ball of information. And we make, we need to make sure that we open up enough windows to ensure that we understand the model as a whole. And that we're confident that we understand the model enough in its entirety to get the job done to realize the system successfully. We also need to make sure that each of the views is actually consistent with each of the other views. Because when we have a model, one of the inherent features of a model, or one of the attributes of a model, is that all of the information is in itself so consistent. If it isn't consistent, then it isn't a model. It really is as straightforward as that. So we need to make sure that our, you know, it is a true model and that all the views are consistent with each other. The way that we communicate these views to the different stakeholders. So in the last presentation, we spoke about how important communication was. And communication is key to everything that we do. So one of the things that people will say at this point is, well, we need to have a common language, which is absolutely true. And then what they'll say is, and we're going to use, for example, CSML as that common language. Now, one of the things that we have to bear in mind is that when we talk about a common language, there are two aspects to that common language. There's what we refer to as the spoken language and what we refer to as the domain specific language. Now, let me give you an example of what I mean by that. I could take this slide here. Now, bear in mind, we've got an international audience present today amongst all the participants. And the number of those the people attending will speak different languages. I could take this slide here and I could present this in, for example, German. I'm doing it in English at the moment, but I could present exactly the same information in German. I could do it in French. I could do it in Dutch. I could do it in just about any language I want to. It wouldn't change the information at the heart of this. It wouldn't change this slide. What it would change would be the words that I'm using, the language that I'm using. So dare I say the spoken language that I'm using to communicate with the different stakeholders. Now, this is very important because the core information isn't changing. What I'm changing is the spoken language that I'm using to communicate with different sets of stakeholders. And the reason why I would do that is quite obviously because different stakeholders with different backgrounds speak different languages. And when we do MBSC, this is the same. We have exactly the same thing that happens because what we do, we have a choice of notations that we can use to communicate to different stakeholders. And this is where something like CISML would fit into this big picture here. So CISML is an example of a notation, but in the same way that English is an example of a language. But in the same way I could speak other languages but from English, I could also speak in other notations. I could speak in UML. I could speak in BPMN. I could do it in formal methods such as VDM or Z. I could do it in tables. I could do it in text. From an MBSC point of view, it doesn't matter which notation I choose here. And in fact, in reality, I might use a number of different notations for any particular system development because different stakeholders that I talk to might speak to each other in a different way. Now, I'm going to do something that I know I'm going to regret now. I'm going to try and draw something again, but there we go. So for example, let's imagine that we had a view where we wanted to identify individual requirements and number them, for example. I could do that in system L using something like if I wanted to. No, don't worry about the notation. That's not important though. Using something like a requirement diagram. So this might be requirement number one. The system shall do X to Y. I could do the same thing in UML. I could use a class diagram, for example. So this would be requirement number one. The system shall. I could do it in text. The system shall do X to Y. Call that requirement number one. I could do it in a tabular form where I have the requirements and then I have the descriptions. So requirement number one. The system shall and so on. What I have here is four different spoken languages, four different notations that I'm using to describe exactly the same information, exactly the same view. This is important because MVSE doesn't care which particular notation we want to. We choose the notation based on the stakeholder that we're talking to. So for example, we could show, we could use things like system dynamics and we got someone's just put some examples up, causal loop diagrams. If you're into safety, we could use Ishikawa diagrams, you know, fishbone diagrams. We could use electrical wiring diagrams. It doesn't matter. The key point here is we use whichever notation, whichever spoken language, our target audience, the stakeholder that we're trying to communicate with is comfortable with and is fluent with. This is what we refer to as the spoken language, okay, and that's where things like SysML fit in. Now one of the big myths about MVSE is that MVSE is all about, is all about SysML and this is simply not true. We use whatever, we have to use a notation but we use whichever notation or mixture of notations is appropriate for what we want to do. Also there's another myth related to that that says that every view that we create must be created using SysML and again this is nonsense. We use whatever is the most appropriate thing. So if you think of the model as being the big ball of information and each view being like opening a window into that big ball of information, when we look at, when we apply a notation to this that's like applying a lens or a filter to that window. We're looking beyond the window at the information beyond it. We're seeing the same thing but we might be seeing it coloured from a different point of view or filtered slightly differently. So when we talk about a common language there's two aspects. The first one is the spoken language. That's like saying let's all speak English or let's all speak German. In MVSE terms this might be like saying what let's all speak SysML. However just because we're all speaking SysML does not mean that we will avoid all misunderstandings in the same way that if we said let's all speak English that we'll eliminate all ambiguity and all misunderstandings. So this is a very important point here is that SysML we think of the spoken language that sits on the right-hand side of what we've got here, the right-hand side of MVSE in the slide. If we start to move to the left now, now bear in mind that we want to, we've already said that we want to capture some information about each view. We want to capture the who and the why for example. We capture this in what's known as a viewpoint. Now here the terminology can get a little bit confusing because viewpoint and view are similar ways. We adopt the ISO terminology wherever possible. So we're adopting the terminology from ISO 42010 in this case. But the viewpoint we can think of there's a bit more to it than this but in simple terms you can think of it as a template for a view. Because if we were doing this in a document-based approach and we wanted people to work in the same way and to have the same look and feel, then we would generate templates in Word and we would fill in the gaps and the templates would tell us the structure and the content of the view. And this is exactly what we have here. We have the viewpoint and the viewpoint contains the who, which is which stakeholders, the why, which is what are the benefits or the value, but also it contains what, what's the structure and what's the content in each view. Now to explain this let's take a step back and let's imagine that when we are dealing with our system, so I'm just going to write the word system up here. Does everybody understand this exactly the same definition of the word system? And the answer is no because different people have different interpretations. In the same way if I have the word requirement there and I have the word capability for example and I have the word function, these are all words that we use on a day-to-day basis. However, different people or I should say different stakeholders might interpret these in different ways. So for example I might say that a requirement describes a system and a system exhibits capabilities and that functions realize requirements. That's one way to interpret that however somebody else might come along and say no, no, functions realize capabilities okay. Capabilities describe our system and requirements describe our capabilities. Somebody else might come along and say well they interpret this differently again. So they might say that requirements describe functions okay. A system comprises functions and that these functions describe capabilities. The point we're trying to make here is that all of these the purple, the red and the orange are perfectly valid depending on a particular set of stakeholders backgrounds, depending on their interpretations of things okay. So what we've got here is you know the red stakeholder believes one thing, they use the same set of terms, the purple stakeholder believes another thing, they use the same set of terms and the orange stakeholder believes another thing and they they have the same set of terms. Now I'm just going to rub some of these colors off just so I can take the discussion further so hopefully that makes sense to you. There's no particular reason why I'm keeping the orange one it's just a little bit neater. I'm not saying that this is the exact definition but what you have to bear in mind now is that we might have one particular stakeholder that might only be interested in the system level so the systems and the way that they relate to capabilities. We might have another stakeholder that's interested more in requirements and functions and we might have another sorry another stakeholder that's interested in the relationship between the systems and the requirements. So what we've got here is three different stakeholders purple yellow and red that are actually interested in different aspects of my overall system okay. What we've got here with these blobs this is what we mean by the structure and the content. The structure is the shapes and the lines and the content is what's written inside each of the shapes. So for each view the information that we capture in the template in the viewpoint is well who or which stakeholder is interested in that why so what are the benefits or the value what's the structure so which of these shapes and lines and what's the content what about the language that I'm using. When we define things in this in this way we refer to this as the domain specific language okay because whereas CISML is given as the basic communication mechanism that we need in order to communicate with the different stakeholders what we're seeing here is a language that uses that so it's like saying I'm using English to express this but I'm defining these particular concepts in terms in a particular way okay. So this is the domain specific language or the the fancy word that we use for that in MBSC is the ontology so what we find is that each of these viewpoints is based on this ontology the ontology being the domain specific language so when we talk about a common language for MBSC so a common language there's two aspects for that which is the spoken language which gives us the basic communication mechanism and the domain specific language which are our ontology and it's the combination of these two that gives us this true common language that we use to communicate our concepts. When we put the ontology together with the viewpoints that's what we refer to as a framework and what the framework does it provides a blueprint or a plan or a schema or whatever you want to call it for our model it's the framework that gives me this consistency allows me to ensure that all of the information in my model is consistent therefore it is a valid model this is captured in my framework and this is done with the ontology and the set of viewpoints the set of the set of templates that we have there. The framework is all about the information that's contained in the model because the model is all about information what the framework doesn't tell us necessarily is how we use that information so for example it doesn't necessarily have a methodology or process associated with it we capture this how we use it how to use the framework with what we're referring to here is a process set so one of the questions that were asked all the time people say well i'm using agile to do my system development therefore i'm not using nbsc this is this is simply not right because agile is really it's a methodology and this is where the methodology sets is here we can still have a framework in place we can still apply all of the modeling we can still do nbsc because agile when look at it from this point of view it's just a small part of the big picture of what we're trying to achieve with systems engineering here um so this is going to tell me how this is going to be the processes in what order we do things what steps we go through and the framework is concerned with the information associated with that okay when we put these things together we refer to this as nbsc in the slide okay so we have the general approach on the left hand side which is the process set in the framework we have the system this is what we're trying to achieve on a day-to-day basis and we have our visualization this is how we communicate with the different stakeholders in order to do nbsc properly we need all of these things in place now i appreciate it's called nbsc in the slide and it's taking me 10 slides to explain this and there's a certain amount of irony in that um but i can take this further by calling this nbsc in the slide and a bit and introducing this idea of a tool and this idea of a standard so let me start with the tool the tool gives me something that allows me to implement the notation and this tool can range from pen and paper to a drawing package such as vizier or powerpoint to the modeling tools the sysML modeling tools might be used to seeing but also simulation tools matlab simulink management tools so requirement management tools like doors um uh microsoft projects any sort of tool that we can imagine that's where this sits and what this is going to allow me to do is to implement my notation okay this is interesting because if we consider pen and papers at all it will allow me to do my notation so let's for the sake of this discussion say my notation is sysML i can do sysML using pen and paper however that line there and that line there is going to have to come out of my head i'm going to have to apply that myself because pen and paper doesn't know how to do that if i choose a drawing package that says vizio vizio will allow me to do the notation vizio has a set of templates um defined in it and that will allow me to do the diagrams but vizio won't allow me to do these diagrammatic consistency checks so the equivalent of the spell check and the grammar check for the language that i've chosen whereas if i choose a proper modeling tool it will allow me to do those this line is interesting because this line is showing me that i implement i can implement the framework and this is not obviously not there on all tools but this is where things called profiles come in so if you've ever come across nbsc profiles in the modeling tool this is essentially what a profile does it allows me to take my approach and embed it as part of my tool so the tool here is implementing my framework okay we move to the top left hand corner we got this idea of standards and by standard i'm using that in a very broad sense and what i really mean by that is any best practice model or any best practice reference so it could be an iso model it could be an in-house work instruction it could be legislation or you know a piece of law doesn't really matter what there is but the key point here is we want to make sure that our approach so both our process set and our framework complies with the standard so for example a standard that we might choose to use for the process set might be iso 15288 which is software and systems engineering lifecycle processes and for my framework i might decide to use something like iso 42010 which is architecture framework descriptions okay this becomes a very very powerful diagram because what it allows me to capture is essentially the mbsc capability of a particular organization or a particular part of an organization or organizational unit so for example in my day job we do a lot of help in different organizations deploy mbsc into their business and one of the first things that we need to know is what's their current capability what have they got on here now so for example some organizations will start off and they will just buy a tool okay one of the big myths that we have about mbsc is people will say well it doesn't work we tried mbsc and it was just an overhead it took too much time people didn't know what they were doing but then when we investigate well how did they go about doing mbsc and it turns out well they bought some tools and they gave them to the engineers well they're not doing mbsc they're just doing one small part of it so this is not a terrible first step but it certainly is a terrible final step different organizations and different types of organizations will start in different places and we'll have a different emphasis so for example we found that we i mean unfortunately are working lots of different industries if we work in say medical devices the emphasis is over here it's on compliance with standards and legislation so that's their start point that's where they want to begin a lot of work in aerospace and defense their start point might be the framework okay quite often in software it might be about the the tool to begin with it doesn't matter where you begin but you need to be able to look at all these and consider each one of these things in in here in order to have a full and complete implementation of mbsc and as i said we use this all the time we use this on a daily basis to help us understand well where is an organization now on here and where do they want to be and it's a combination of three things it's this the mbsc capability it's the mbsc maturity or the evolution which is what we spoke about in the first presentation so these are two things that you need to know where am i now on here where am i on the lego figure and where do we want to be on here and where do we want to be on the lego figure and the third thing that we need to understand to do mbsc properly is why why do you want to do mbsc in the in the first place what benefits are you trying to get what are the expectations for mbsc and that's what i'll be talking about in the third and final presentation in this series is the benefits of mbsc and the why of mbsc so this is what we refer to as mbsc in the slide we need to consider the system aspect so the system itself and remember this is our day job we must never lose sight of that the model this is our single source of truth or our single point of reference the basic constituent part of a model is a view each view is a collection of information but it must contribute in some way for the model because the model contains as much information as necessary to develop our system not as much information as possible in order to ensure that the each view is relevant we ask who which stakeholders and why what's the value we also need to know the structure and the content this is all contained and captured in the viewpoint and the structure and the content is based on the ontology the combination of the viewpoint on the ontology gives me the framework and the combination of the framework and the process set so the framework is all about the blueprint for the model the process set is all about how we use that so the process the methodologies the methods that we're using this forms our approach our approach must form part of our overall compliance where we make sure that both our process set and our framework comply with a best practice model or a best practice source we just refer to that as standard the way that we visualize our model so the views in our model so the different stakeholders is we use a spoken language we use a notation to do that and we can use whatever notation whatever spoken language is appropriate bearing in mind the stakeholders that we want to communicate with and the way that we implement this in reality on a real project would be using a tool a tool will allow us to implement the spoken language and the tool will also allow us via a profile to implement a framework and therefore our domain specific language and remember these notations and tools aren't just restricted to things like sysML they can be safety related things they can be simulations mathematical based notations and tools they could be management notations and tools nbsc doesn't care what nbsc cares about is that all of the information that forms part of our model is consistent with each other so that means that our electrical wiring diagrams will be consistent with our heat flow diagrams will be consistent with our mathematical simulations will be consistent with our sysML based scenarios for example so this is the summary of the second of the presentations and this is nbsc in the slide so we use this to summarize nbsc but also to determine our capability or nbsc capability we can use this as a basis for our gap analysis so we can use this to say where are we now and where would we like to be and also we can use this to understand tools because when someone's trying to sell as a modeling tool quite often it will come with a particular framework in place or a particular set of processes in place or a particular notation by overlaying what our tool is given us on here it gives us a very powerful way to allow us to understand what the tools are doing and as I said we use this on a daily basis within our organization the slides with the hand-drawn notes that I put on them when we finally got them to work they will be made available I'll send those over to Thomas so he can make those available to all the all the participants and everybody the video will be made available also if you go to our our knowledge base you can see things on there as well join us on LinkedIn Christmas is only around the corner if you've got loved ones and they like to read buy them some of our books the particular topic we've been talking about today is covered in the Incozy UK publication don't panic which is that one there and also if you'd like to know more in your Incozy UK does run courses through their indoors training provider scheme on this subject they do them online for an international audience and they also do in the face-to-face for a UK based audience and if you're a loose end at the end of September there'll be a very large MBSC event running in the UK so that's the that's the end of the presentation so apologies for the hiccups the technological hiccups that we had part way through I'd like to thank so many people for coming along and attending and I'll be happy to answer some questions and it was me all along so let's have a look at some of the yeah thank you very much so far John my small feedback from my side I really love this single slide it's so easy to read and even if you don't have much further knowledge or so it's just simple to understand I really love it and I can also highly recommend your book MBSC Domestified where you get much more in depth and yeah it's really great so okay thanks Thomas so we got a number of questions here so I'll answer a couple of them so let's look at the so we got one from apologies if I miss financial name Karen Bagdo who's saying do we eliminate requirement documents totally if we use MBSC this is an interesting question if we take this further and say do we people often say are we trying to get rid of documents and the answer is no because what we do in MBSC the way that we consider documents all we're doing is we're changing this there's nothing inherently wrong with documents the problem with documents is if you've only got all of the information as we said again in containing documents then maintaining the consistency of that information is very very difficult if the information is contained in the model and then we want to document based on that information we can do it in whatever notation we want using whatever tool we want and depend on the tool in some cases it's possible to automatically generate those documents so I don't think we'll ever see a world where we no longer have documents but from an MBSC point of view when I produce an English based document using Microsoft Word for example all I'm changing there is the visualization so the notation to the English language and the tools to Microsoft Word and if we can if we can look at it like that if we can visualize it like that then what we end up with is documents that are actually consistent with all the other documents because they're based on the model and the consistency of that is guaranteed with the framework and in fact we deal with a number of clients where we actually have an MBSC approaching place that doesn't use any notation like SysML or UML but he's purely text based now having said that it's a lot more difficult to maintain that consistency if you're not using for example a semi-formal notation like UML or SysML or something like that or something more rigorous but it is possible to do that so I think we will always have documents there but from an MBSC MBSC points of view when we produce a document all we're changing is the right hand side of what we've got there so we've got let's look at another couple of questions right so when using multiple notation tools etc in one project how does this use from Tisse Neuven-Huyzen I think that's or something similar or TICE that sounds Scandinavian to me when using multiple notations tools etc in one project how does one ensure consistency in the model as it's now not containing the single tool now this comes down to implementation it's a very good question because what we have here in the framework has to be contained in a tool somewhere sometimes in multiple tools if we have this framework captured the framework and the processor is independent of the notations and tools now what this means is if we have on the same projects we're using different tools but we're actually adopting the same framework then it's absolutely possible to have consistency across all these different tools that we're using here it's not as straightforward as when we're using maybe just one or two tools because it then comes down to the issue of tool interoperability and what many of the tool vendors actively don't want is full interoperability between their tools and competitors tools for obvious reasons for commercial reasons so it's absolutely possible and the simple answer to that is we make sure that the framework is well defined in a practically in real life it's going to come down to the capability of the tools and the tool interoperability issues that we might have when all the slides are available I agree it might spend some more there we go there we go slides will be distributed right so we've got Miriam Beth and Bine you described the framework as being the result of viewpoints and ontologies but aren't frameworks often defined independently from a particular project yes absolutely because ideally what we should have is the same framework that we can apply across multiple projects it might be that the way we generated the framework in the first place so let me give you one possible scenario we might have a document-based approach to systems engineering so again consider these as the right hand side here as the notations we then abstract those interviews and viewpoints so we might abstract our framework from a particular systems engineering application on a particular project however what we should aim for is to have this framework consistent and independent of any particular project what we might have and this is very important here is we might have multiple process sets that apply to the same framework so on one project there may be one that's quite well understood that's not particularly complex we might be using an agile approach for example on another project we might be using a linear approach for example we can use the same framework for both of those so the framework this is what's essential here because it's the framework that's going to give me the consistency across the notations and the tools and indeed the different process sets or methodologies that we might be using across an organisation so we've got Sandeep, Sandu how do we maintain version levels if even the model changes or requirement changes how do we revise and keep the version level thanks this comes this comes back to our organisational processes the model itself and it's a very good question it's well presented as well the model itself is a living entity it's a living beast okay and as such it will change as time goes on and we need to be able to control that to control the evolution and the growth we had another question about the growth of the model as well and how do we how do we control that is we need to have good change control and version control processes in place in our organisation that are applied to the model and this is essential because otherwise it is easy to lose control of the model so that comes down to our organisational processes which I would hope would already be in place in the organisation but as I say the evolution of the model needs to be needs to be contained we've got maybe time for one more question we've got Adrianne Pines who or well in the UK we'd say hoff who knows how that's pronounced where you are in my experience the model is not only useful during the development phase of a new project but also to support engineering change further in the life cycle this is absolutely perfect the way that we define our MBSC the way that we define our approach we should be using MBSC to do that for some reasons if I said to you we should apply systems engineering to complex projects everybody would agree if we said well hang on our new projects is going to be deploying MBSC into our business that's a complex thing to do we should be we should be using systems engineering to do that so yes the takeaway from that is quite a long question this is use case in stakeholders and the caption of viewpoint absolutely we apply the same techniques to our actual approach for doing things it sounds a little bit Dr. Zeus because we're using one thing to define itself it is easy to tell yourself in circles but we should be applying MBSC not just to the development at the model of our system but if we consider the whole deployment of MBSC as a system we're going to apply these apply these same techniques to defining our approach as well okay and then there's a question from Francesco can we say that the benefit is to dot dot dot I'll be talking about the benefits of MBSC in the next presentation when we talk about different projects do you mean different products either or both depending on what your terminology is that you want to do so it could be products it could be projects we've got a whole list of questions from Nitin in NIAC question number two I'll take because it's shorter how does architecture and data management fit into this slide for example CAD layer right CAD fits over here okay so we'd use the CAD notation there the mathematical type notation and we'd use math CAD or something like that or whatever the draw the CAD packages here the key point there is what MBSC cares about is all your CAD information is consistent with all of the other information and I think that's probably about all that we got time for so Thomas is that all okay with you it's great thank you very much again John it was a great presentation I will send this slide over to you Thomas probably tomorrow morning now and then if you can do whatever you do put them on the website I'll do whatever you do with them that will be that will be great okay so thank you again we will close the session now and one more thing I would like to express thanks to again to look at Martin Corporation who is sponsoring the COSY webinar and yeah what's more to say we planned next part three in the end of May the exact date we are negotiating at the moment but yeah it will be at the time again so again thank you very much John thank you very much to every participant I hope you enjoy the show and goodbye okay thank you everybody goodbye all right sneak to get off