 Sorry, because my German is very limited, so I will speak in English. First of all, thanks Christian for the introduction. Thanks for organizing this webinar, and thanks for inviting us. I will not explain my resume. The important thing is that I am the author of the methodology at IUC and PPOA, and this methodology is the result of my work as an engineer, part-time professor. I work as an engineer in diverse areas, for example, real-time systems for air traffic control, avionics, scale assistance for nuclear power plants and coal power plants, and cellular phone applications. Currently, I am working in medical devices. The second part of this webinar will be given by Alfonso. Alfonso Garcia is an independent systems engineer and consultant. He's an industrial engineer from the University of Polytechnica de Madrid. He's in course 35 systems engineer professional. He has more than 13 years of professional experience as a systems engineer, and he's involved in different engineering projects, including avionics, automotive, and elevation systems. Currently, Alfonso is working in our team, the IUC and PPOA team, and is our expert in the cameo tool. The content of the presentation, first, I will give, for all of you that perhaps do not know the methodology, I will explain it briefly, the IUC and PPOA, the conceptual model, and the methodological process. But the main part of the webinar is the presentation of how we deal with functional architecture, using a combination of traditional methods and system notation, and how we implement this in the cameo tool with very good results, because part of the functional flows are obtained semi-automatically. We will finish in the second part, and Alfonso, we will explain the example of an electronic parking brake system developed with this methodology, IUC and PPOA, and the cameo tool. I will explain the foundations and dimensions of the methodology. First, I think all of you understand what is a model-based systems engineering methodology. You have the definition of Jeff Steffan, in this definition of Jeff Steffan for Incosi, a methodology is the combination of a process or some processes, some steps, some methods or best practices, and a tool. Unfortunately, some companies are focused only on the tool, and they think that having a tool and using CIML notation, they resolve the problem. I think that the problem really is teach to the engineers how to think, and this is more important, so it's more important to have good processes and good best practices or methods. So a methodology, IUC and PPOA, is a methodology that evolves for an architectural framework. The architectural framework for real-time systems was called PPOA, Pipelines of Protheses in Object-Oriented Architectures. This is a framework for real-time systems that also we develop a tool. We develop a tool using UML notation. We extended this framework for software architecture to integrate systems engineering, to integrate model-based systems engineering. So we develop the methodology IUC and PPOA. This methodology currently is tool agnostic, so you can use whatever tool supports CIML, basically. Okay? Really, we are using four different tools, and currently, we are using CAMEL. ESFP is a, this methodology is a requirements-driven. So requirements are very important to drive the architecture, and the architecture is very important to drive the requirements flow down. So a methodology, as I understand, is a way of thinking consistently, and is not a problem or obstacle for creativity. Sometimes I have the problem with some customers or students or professional customers that they think that the methodology is an obstacle for creativity. It's not the case. In this methodology, you have several milestones, when do you have to make decisions that your creativity is very important? This methodology has three dimensions. The first dimension is what we call the mission dimension. In the mission dimension, we look at the system from out in, from outside. The system is a black box. The system interacts with actors. These interactions are described by an artifact that is called the scenarios. From the scenarios, we obtain user needs, operational needs that are requirements, but specified from the point of view of the user, not from the point of view of the system. These needs are aggregated as capabilities. Capabilities are the ability to perform something. This is the first dimension. The second dimension is the system dimension. In this dimension, we look at the system as a glass box. So we look inside the system. We identify system requirements, and we identify the thing, the artifact that we will today talk more deeply about. It's functional architecture. We identify the main functionalities, and also we identify the functional flows, the behavior. It's important because other methodologies don't put too much attention to identify the functionality. They think that they are object oriented. I think functionality is very important. It's very critical. I will explain it later. Here we develop the physical architecture using typically C-SML block definition diagrams and C-SML internal block diagrams. The third dimension is the software dimension or software intensive system or software intensive subsystems. In this dimension, the artifacts are the domain model that is the bridge between the physical architecture and the software architecture. The domain model is a domain model representing the main classes to be implemented by software using a UML class diagram. It's very important. I remember working for a large space company, very important in the world, developing the domain model of aircraft trajectories for a tool they are developing for simulation aircraft trajectories. On the domain model, we obtain the main software components and we represent them with a structural view using UML class diagrams. We represent the behavior of view of these software components using mainly UML activity diagrams. Here also, for the behavior in the system dimension, we use activity diagrams. The activity diagrams are using from behavior, description at the system level and at the software level. As I mentioned before, this methodology is requirements driven. What do we mean by that? We mean by that, that requirements drive the architecture. How do they drive the architecture? We have the system requirements. From the system requirements, we perform functional analysis. Performing functional analysis, we identify the main functionalities to meet these system requirements. These main functionalities are allocated to subsistence in this first level. We use the non-functional requirements and constraints to drive how the subsystems interconnect between them. Functional requirements are allocated to subsistence and non-functional requirements are implemented. From these subsistence, we have also a specification of the subsistence requirements and we go to the next level. Going to the next level, we apply again the functional analysis. So we go down in the functional hierarchy. We have more levels in the functional hierarchy. So we have to allocate new functionalities, new functionalities of lower levels. Allocating these new functionalities, we identify the blocks of each subsystem. These blocks are interconnected by connectors. These connectors, in some cases, are identified using non-functional requirements. When we have the subsistence architecture, when we have these blocks and the parts, we can go to the next level, that is the component design. Each component, if the component is implemented as mechanical component, the mechanical engineers will design this component. If the component is implemented as an electronic component, the electronic engineers will implement will design this component. I mean, if the component is implemented as a software component, the software engineers will implement, will design and implement this component, but this is very important because the requirements flow down is driven by the architecture. That's very important because requirements flow down is one of the most difficult activities for engineers. We use in this methodology three main best practices, the use of hierarchies, the use of flows and the use of bridges. We use hierarchies or trees for functional architecture, quality attributes, physical architecture and requirement diagrams. So very important this hierarchies. We use flows for represent behavior. These flows are represented by CISML activity diagram. And we use bridge to cross over some semantic gaps. There are two main semantic gaps. The first semantic gaps is the semantic gap between non-functional requirements and physical architecture. This semantic gap is bridge by a bridge that is called heuristics. We apply heuristics to bridge that. I will talk about the use of heuristics in this methodology in the INCOSY 2021 conference on July. Today, I have no time to talk about that. And the domain model is the bridge between the physical architecture and the software architecture. The domain model is a representation in UML class diagram of the main concepts that you are interested in implemented by software. So, as I mentioned before, we use hierarchies for physical hierarchies. Functional hierarchies is the most difficult for engineers to build. And I recommend here mentoring and training. It is my experience with professionals and also students that this is the most difficult. I remember an experience with the art traffic control system of UK. I was consultant, external consultant of the company developing the flight plan processing of the art traffic control system. And one of the main problems was to have a good functional hierarchy. Another character important is the quality attributes. When you have quality attributes, for example, safety, maintainability, reliability, resilience, etc. And you have the non-functional requirements that are dependent of each quality attribute. I will explain briefly the conceptual model or the ontology that supports this methodology. I developed this methodology for understanding the terms that are used in the methodological process. The main term here is the system. Our system of interest. Our system of interest interacts with an environment. This interaction is described by an association class in UML that is called operational context. So the interaction between the system and the environment is described by an association class that is named operational context in the methodology. This operational context is an aggregation of scenarios or use cases. From the scenarios, we obtain operational needs. Needs are requirements but specified from the point of view of the actor, not from the point of view of the system. So the subject of the need is the actor. For example, in a medical device, the surgeon needs to know the temperature of the patient. Not the system shall monitor the temperature of the patient. This is a system requirement. The other is operational needs. Operational needs are transformed. Some groups of operational needs are transformed into capabilities. Capabilities are of the systems. What is a capability? A capability is a ability to perform something. The systems have capabilities. Capabilities are complex. For example, in a human aircraft vehicle, the capability is long endurance. Long endurance is a complex capability that is an aggregation of properties. For example, quality attributes. For having long endurance, you need to have high reliability. For having long endurance, you need to have a wide span, a long wide span of physical property of the wing of the aircraft. To have long endurance is recommended to have some functionalities regarding health monitoring. So a capability is a complex property, a complex combination of properties that can be quality attributes, states, physical properties or functionalities. An important issue in this methodology is that we differentiate that normally the majority of the properties are allocated to system parts. But some quality attributes specified by non-functional requirements can, it's not possible to allocate it. You have to implement this, a different word, allocate for implement. Some non-functional requirements for simple safety are implemented using heuristics. This is a very important issue in this methodology and is an important feature of this methodology that makes it different from other methodologies. I am not in right now I have no time to compare with other methodologies, but I have studied the majority of them. These slides summarize what I mentioned before, so I will skip. We have a methodological process. Today only we will apply this part of the methodological process, but the methodological process is more complex. First, this is the part related with the mission dimension, where we identify the scenarios. If we identify the top level requirements, in the case of primary graphics are the top level high-graph requirements, and we specify the quality model, the quality model, and the main quality attributes. From this mission dimension, we go to the system dimension. The first part of the system dimension is to build the functional architecture. And the functional architecture is built with these steps. You can apply it iteratively. When we finish the functional architecture, we build what we call the modular architecture. The modular architecture is the allocation of functions to modules. Modules are logical components, integrating functions that are highly cohesive. When we have the modular architecture, we refine it using the heuristics to apply to meet the non-functional requirements. So this is very, and is all as well, an interactive process. When we think we finish the functional allocation, when we identify all the functions, we identify all the functions of a system, when we have for all the outputs that we identify in the system, a function that produces each output. This is the main criteria I use. So it's very important to identify the outputs, and the outputs are what the functions produce. So the functional requirements are specifying the output of each function. It's very important to understand that. It's difficult, but if you understand that, your functional architecture and your functional requirements will be very improved. So we produce these artifacts, the functional hierarchies. This is very simple. We produce functional interfaces, and here we use the n-square chart that is a traditional systems engineering artifact. The important thing is that we implement it in cameo. Alfonso will talk about this later. So here we have the functions in the diagonal and the items in the cells. The convention I apply here is input in columns. So item one is an input of function one. Item two is an input of function two. Item three is an input of function three. Above the diagonal are the items that, for example, function one sends to function two. Below the diagonal are the feedbacks. With this information, this information is extremely useful for building the functional flows. Alfonso will illustrate it in the electronic parking brake and using cameo. If you have this, both of these, you obtain this semi-automatically, not automatically, because the engineers still need it. The second group of artifacts is the physical architecture. We have two systems. We have internal block diagrams for each system, and we have functional allocated functional flows when we have the function allocated. Here we are using in CML allocation by usage. Function F2 is allocated to part B, to part B here. We have also this merge decisions, whatever. Parallel, join, forks, join, etc. Why we defend here that the functional architecture is very important? Because as engineers, we work with functions. The systems have functions. The systems have functionality. The problem is that the concept of function is ambiguous concept. Nobody understands the definition of function. For us, as engineers, a function is a transformation, a transformation of matter, energy, or data to matter, energy, or data. So when we identify a function, we identify a transformation, where it's very important the inputs and the outputs. The function architecture is a representation of the problem space. It's independent of the technology. So it's very important because if the product evolves with technology, the functionality does not evolve in the same way. An aircraft has the same functionality all over the years, more or less. An automotive, in some cases, yes, have the same functionality. So it's very important to have the functional architecture as an asset of the organization. In the case of Inkoze, Inkoze develops the functional architecture of an aircraft, and it's very useful. I use it because he has one of his main assets, the functional architecture of a commercial aircraft. Some object-oriented MNVSE methodologies approach, promote, identify first the physical architecture and after the functionality. I disagree with that. I follow a principle that is a principle used by traditional systems engineering and borrowed from buildings architecture. This is the principle state by the architect Louis Sullivan. He's an architect of the 19th century. This principle is form follows function. The design of the building is based on the functionality of the building. So the functional architecture is very important for identified performance requirements. We have the functions and we identify the performance of each function and we can allocate the function or we can allocate the function plus the performance requirement. There are two approaches here. I show people that prefer allocate functions and these people that prefer to allocate functional requirement must plus performance requirement. Functional architecture is very important for safety analysis. Functional architecture is the core model for mechatronic systems. So the functionality is independent of the implementation. The implementation of the function as a mechanical component, an electronic component or either a software component. For mechatronic systems, the functional architecture is the core artifact that integrates the diverse engineering specialties. Here is how we develop more specifically the functional architecture. We develop the hierarchy. In the hierarchy, we identify a group of related functions and we apply the n-square chart. From the n-square chart, we identify the functional flows because in the n-square chart, we identify dependence between functions. For example, a function sends an output that is used as an input by the next function. This sequence is identified in the n-square chart. The functional hierarchy is very important because we have the functional coverage of the system functionality in the functional architecture and mainly in the functional hierarchy. We apply the principles of functional cohesion and sequential cohesion, very important principles to build the functional architecture and it is very important to have a consistency between this functional architecture and the physical architecture. Alfonso will illustrate it in the sample. As I mentioned before, for us, it's very important and we implement it in cameo to use the n-square chart. In the n-square chart, we have the functions in the diagonal. In this row, we have the inputs from external to this group of functions and in this column, we have the outputs external to the group of functions and we use here the input in columns convention. Function n sends this output that is an input function p. The n-square chart is very, very useful. It's similar to another artifact that is called the design structure matrix that is very used by the Massachusetts Institute of Technology and the Technical and University of Munich. We have functionality and we use the functional hierarchics and the functional n-square charts to build the functional flows and the functional flows are built using CISML activity diagrams. In some case, for example, in the activity diagrams, we recommend, this is an heuristic. In some case, where you would like to avoid undeterministic behavior, we recommend in the activity diagrams to use in interruptible regions. I recommend you to know more about that, to look at chapter nine of the book, of the book of the methodology. I will hand over Alfonso to the second part of this webinar. Okay, thank you very much. I will share my screen and continue from there. So can you guys see my screen right now? We do. So great. So as we have seen the overview of the methodology, now we can jump into how to define the functional architecture of this elective parking brake system. And that's because as I said, we are going to do it in three steps. First, we are going to create the functional hierarchy, that functional tree, and then we are going to define the functional interfaces from the functions that are identified from the tree and use these two artifacts to create this functional flow, to represent this functional flow, that this compendium of the structural plus behavior creates the functional architecture. But first and foremost, we need to understand the problem. And as we were no experts in elective parking brakes, we took a deep dive into the internet to look for what is the language when people are creating this type of system, what are the concepts, the mission, the side functionalities, what possible design they are there, what are the important aspects like safety and the like. And based on that, we started to define the problem. And we started with the mission dimension, we remember from the previous slides. And in the mission dimension, the first thing that we should create is the system context. So where is our system talking to which external entities not to deliver its value? Because remember, the functionality in the end is a disemergence of all behavior, but it is the same when the system operates in its environment. So based on that, we can start to define the approach in scenarios, not to define how our system is going to interact with its external entity, not to deliver its functionality. We can do it in a text-based way, like write down what are the actions and reactions of our system, or we can go for a diagram based scenario, not to define the scenarios using activity diagrams. The advantage of that, even if it's more complicated, it's more complex to do it in the right way, is that we can easily identify what are the external changes at a glance. Once we have cleared a set of good operational scenarios, we can start to extract those needs as was talking about before. From the perspective of the user, what does he mean? For example, that the driver can easily engage right now to retain the vehicle after parking, within a determined time, or that the driver can leave the vehicle even if he didn't remember that the car is secure in place, because in the end, the system is going to recognize that hazardous situation and automatically engage. So once we have a set of needs, we can cluster them to create this high-level artifact that is the capabilities, this ability of the system to perform a determined effect that is really important and simply understood by the customer, and so that he wants from the system, comfortable control, easy to use, like picking a button or something like that, or that the system increases the safety, identifies hazardous situation and engages and retains the vehicle and doesn't allow it to get hurt, but that the system itself, when the environment changes, they break back that work out or the temperature changes, for example, that he needs to increase everything and for that. So while we have that, we can jump into the system dimension. But I put this slide here to tell you that as we are using a modern tool, and all these elements are connected together, that you can easily control the evolution of your modern artifacts. You can see easily what are, what the capabilities are important to you to be the first, because the first one is involving more operations and they are related through the needs. So you can do this kind of table and mattresses that are quite useful. So now that we have the mission dimension here, so we understand the problem, then let's go and refine the problem and build this functional architecture out of that. So as we said before, there are three steps, the functional hierarchy in the first place, these functional three that describe the top level functions and how through analysis are decomposing to simpler functions that in the end can be allocated to system components. Then once we have that, we jump into the definition of the functional interfaces, what are the dependencies between those identified functions on the tree. And with these two artifacts that we said before, we can, in a semi-automatic way, using cameo, the functional flows that describe the behavior of the system in the end. So if we go to the definition of the functional hierarchy, it's true. As Jose Lee said before also, that the, one of the key, and I need to repeat that, one of the key concept is that the function for us is that transformation. It's transformation of input items into output items. And these items should be matter energy data, for example, but it's the function of a module, it's supposed to start, but it doesn't want to talk because of nothing. It converts the electrical energy into these related to mechanical effort or a car, what does a car do? It transports passengers and the driver with the input from their initial position to their destination, the same input as the output, but the state change. So once we have that clear, is there any help there to allow us to identify in an easier way in this kind of transformation? And yes, as you can look for templates in the literature, like we went from Halde and Peer Bay, that it is for real-time systems, and the classified functions are used in the first control input output processing moment. I don't know, sorry to disturb. The sound isn't perfect, can you, could you just adjust your micro a little bit? It's really not perfect. Maybe a little more distance or closer, I don't know, but it's a little bit, is there something like this constellation, I guess? Yeah, try it. I'm gonna try to change the speaker. We would laugh to have a little bit more volume, so to put it like this. Okay, thank you. Okay, can you hear me now, better? It's better now, yes, thanks. Okay, cool. So as we said, we can use templates, or we can go for looking for taxonomies, like this one from NIST, that is really good for industrial processes, and not only define the cloud, not only glass fly functions and transformations and different types, but also the possible inputs and outputs that you can receive. So based on this, we can start to produce the tree, and we are going to do it into approaches. The first one is using this top-down approach, where we are going to start from the capabilities, and that we define the dimension dimension, and also from the top-level requirements, that Jose just talked about it, but we are not showing that in this example. And then we need to analyze this top-level function and the composing part, where it's a level as we said before, that we can identify elements of the system components. So we are also going to do the other way around, to look for this bottom-up approach, where we start from another active actual dimension, that is the rational scenarios, and for low-level function for here, and you will need to cluster them together, for those that are highly rated, and then you can compose up the tree until you reach the highest level functions. So another concept to keep in mind is this consistency between input outputs, between several layers of abstractions. So for example, if a function receives a transform determined input into a determined output, its children shall do the same. So it might be that this input here is a complex one, and you can divide it up, split it up, so that function 2.1 receives part of the input, and function 2.2 receives part of the input to do the transformation. But in the end, the composition shall be the same, and this is one of the key concepts together with this concept of functionalized transformation. So when we consider that we are finished, is when we can demonstrate that those identified functions from the tree can realize all the midi capabilities, remember that top-down approach, that we can cover all the operational scenarios, remember this bottom-up approach, that we can transform on this scheme all the inputs from the context, this is central input into external outputs, and that we can identify elements of forms, not that can have this responsibility for performing the transformation on the lever side of the tree, and we recommend that we do it one-to-one on a location, so that you don't share the responsibility of performing that function between two components, if it is not a clear analysis of what part of that transformation needs to be allocated to component 1, and which part to component 2, so you should divide this function into two. Okay, and here is how the tree looks like for the parking brake, so you can see here for this topic, you can easily go to the first layer, you can understand that these functions here receive the inputs from the stem up, they present transformation and decisions, until this one is producing the required returning force of the voice that is equal to OSEC, to go away, and these ones are providing some information to the vehicle network, and this one is going to provide the indication whether the parking brake is active or not, whether it's in the vehicle or not, to the driver. So now that we have defined the functional tree, we can jump into the definition of the functional interfaces using this famous n-square matrix, so for doing that the first thing that we need to do is to identify what type of function, what functions in the tree are going to go there, that are important for us also to describe the behavior in the end of the system. So our recommendation is not to stop on the higher level, but to mix the first and the second level at least, so that we can verify using the n-square chart that these second-layer functions are really highly related between them to comprise the parent, to compose the parent. So how do we create in cameo this n-square chart? What we are going to do is to create an activity diagram where we are going to push those identified functions into here, and then we are going to create a dependency matrix that is observing this activity diagram. So every time we push a new function here and this represents an action, it's going to also be updated here and there goes a column, not only that, but when we create an input or an output, it's also going to be shown here as a raw output and the input in here. So the next step would be to create those input pins and output pins that meet each of the functions, and if you type them you will also at the same time create the initial steps for the data functionality, which is a really good thing. So once we have updated the diagram with the input outputs and also the external inputs and external outputs that are needed, we can start to connect them in the matrix by object flow. So then you will get something like that, but we do not stop here. Now we are focusing on the n-square matrix and we need to sequence the n-square matrix. What does it mean? So in the end is that we show through the interactions on the upper triangular matrix we need to reorder all the functions so that the diagonal shows the sequence of transformation from the external inputs that goes into the first functions in the diagonal and then the sequence of transformation like a skating until the lower part of the matrix produces the needed external outputs. So how do we do that? You can follow the rules given by this link that is applied for the n-square matrix and because in the end it is more or less n-square. And these kind of matrix allow us to check whether our identification of the functions was the right one, because in the end it would have, after sequencing the matrix, we have many dependencies on the upper side that follow the cascading that is okay, but we also have many dependencies here as feedbacks. That means that the whole set is totally coupled and there is no way of, you should revise back the identification of function to simplify lower dependency. So you need to go back and think about whether you did identify the right transformation and if it is empty, the same thing, that you have no dependency between functions, they are not a couple. So the good thing is that you have some kind of dependency on the upper side and the feedbacks are the closest to the diagonal as possible because that way you can identify seeds for your modular architecture or also consider that these two are part of a new part in the function of the higher level. And if we go for the example, we can see here after sequencing the matrix that the first, as we said before, the first functions in the diagonal are the ones absorbing, receiving all these deny inputs and then they are producing some output to the to the next function in the diagonal until the functions on the lower side, like produce baking process, produce the needed returning process and these ones are producing the status of the network and dedication for the driver. And as we stop on the first layer, but we also use the second layer, we can verify here, as we said, that the parent was the right one, because these three functions are highly related, highly dependent on performing the related transformation. Okay, now that we have that, we are going to use that information created in the model to create these functional flows in a semi-automatic way. So the only thing that we need to do is to focus back in the activity diagram and just select everything and display the paths that we were creating using the n-square chart. So then you click on reorder automatically and you will get an activity like that. But what is happening here is that if you try to simulate or you really understand the activity diagram, how do they behave, you will see that it doesn't describe the behavior that you would like. So you need to add these control flows and nodes to make the diagram to behave as you would expect. And I highly recommend that you do it using in every step when you have a control flow or control node that you simulate it until you get the right behavior out of that. So you need to decide whether you will have parallel threads or when the term in transformation should be activated based on the terming decision that you need to take. Okay, and here you can see how the behavior, the functional flow, it is shown for the electric parking brake. As we said before, these look like at the n-square chart that these functions here are those ones that are receiving the inputs and then it's the cascading in there until the external outputs from the components are produced. So every time you add the control flows, you will see whether you are closer, a step closer to the real behavior that you want to describe. And now we are in a good position to identify physical entities. You could say, okay, in order to capture the driver model action, I want to have a switch. I want to have a switch with a telting that indicates the parking status to the driver. And for producing braking force, I want to have this integrated caliper that produces the needed braking force based on the braking control scheme. Or to measure inclination, I want to have a tilt angle sensor, or it might be that you need an accelerator sensor. And then you should refine this measure inclination more to say, okay, I want to sense the acceleration and the computing of the inclination based on the acceleration that's going to be done by the ECU. Okay. So as a summary, we have seen an overview of the ICPBOA methodology and what are the important aspects of that. We have seen how to apply the methodology using cameo to create the action architectures, no, with this example, the parking brake system. And we can say that this is a seamless way to create function architecture that easily understood. We have the time here that are validated by simulation and that are consistent with the requirements and the emission dimension. And you have seen that creating the structure by the hierarchy plus the dependencies, you can easily derive, and as you may automatically weigh the functional flow and know the behavior, the functional behavior of the system. So you want to know more about the methodology, you can take a look on the book on practical model based systems in the union that were written by Jose Viz and Carlos Hernandez, where the methodology is detailed, explained with practical examples. And if you want even more, there are some papers published in this website that were published in other conferences. Also dealing with some aspect of the methodology with applied examples for that. Thank you very much for attending the meeting. We are looking forward to answering any common questions that you have. Thank you. Thanks Alonso for giving us an insight. You have a quite complex topic about functional architecture.