 Hey, thank you very much One warning up front. I do have three small children in the house with me. So we may get some exciting interruptions Just before warned if you hear screaming. It's probably all okay As was in the introduction, my name is Tyler Smith I'm a research scientist for adventium labs. We are a R&D company based out of Minneapolis, Minnesota And just because it's been a long day with a lot of presentations that have been really interesting But you've all been listening for quite a while. I wanted to start with a joke I can't hear you laugh, but I'm gonna have to assume that you're laughing. I Wanted to think of a data model joke. This one might be tangential but So helium neon and argon walk into a bar and the bartender says hey, we don't allow your kind here They don't react But umch all right onward with the presentation This presentation is about using several different standards all together that is face and AADL as well as sysML and a tool developed by a ventium labs called sliced I'm going to tell you two significant takeaways right now Then I'm going to go through my presentation and then I will tell you those takeaways again The takeaway number one is that there is no one standard to do everything and If you are setting up a modeling environment For your company for your program office for a platform You need to consider how your modeling environment is going to work with multiple standards and how they work together We saw many of those standards mentioned in the Tucson embedded systems presentation earlier and in the scale presentation So takeaway number one is be ready to work with multiple standards Takeaway number two is that you need to think about behavioral interoperability behavioral interoperability is the focus of the sliced tool and Importantly is not a significant focus of the face standard and I'll talk about that more as we go on this presentation is Focused on using multiple standards together along with using a ventium sliced behavior analysis tool To increase confidence in model integration What I mean by that in particular is we want to increase confidence in behavioral integration of multiple UOPs By using sliced which is a behavioral analysis tool to detect behavior integration errors To do that. We have quite a few different things. We need to address some of them have already been covered extensively and pretty clearly and Succinctly by prior presenters. So I'm going to go through them quickly such as the overview of the face standard and face data modeling Other elements are a little bit newer and I'll spend more time on them Such as the sys ML modeling process with face and a ADL as I mentioned We're talking about several different standards today. I'll touch on them each briefly First is the face standard for the face data architecture Which captures semantic and syntactic information? Related to software data exchanges. This is what Chris Alport talked about in detail when he described the data modeling architecture and data modeling process with face We're also talking about the architecture analysis and design language Or a ADL, which is a language focused on describing embedded systems or cyber physical systems specifically focused on embedded software systems Next we have sliced which is a ventium's behavior analysis tool that analyzes face data models That are annotated with a ADL details such as thread properties and Sliced analyzes them for behavioral integration errors There are different tool environments in which you can do face and a ADL modeling some of those were mentioned in prior presentations In particular for this presentation. We are discussing sys ML Sys ML is one not the only one, but it is one of the ways to do face data modeling And is one of the ways to do a ADL modeling I'm going to show you how we do both of those together in Particular for this discussion. We used magic draw sys ML. There are multiple sys ML tools. We are showing you one of them Again going back to my introductory statements If you are setting up a modeling environment You need to consider different standards and different tools that implement those standards and how those standards will work together In the context of your tools Okay, this press or this slide shows an overview of face I'm not going to talk about this very much because it's been thoroughly covered by the prior presenters Similarly Chris Alport covered the face data modeling process in detail. So I'm not going to add more time on that however, I will talk a little bit about this last detail of the face data modeling process which instead of focusing on the conceptual logical and platform Levels the next step in the face data modeling process is defining the UOP model UOP model Describes a single software unit of portability that references the data model to find earlier. I See a comment that someone cannot see the slide Can I get confirmation from anyone that others are able to see the slides? Either via chat or voice Copy that Emanuel You may want to try switching from the desktop app to the web app or vice versa I had issues earlier today where the web version of WebEx was not working and I had to switch to the desktop app Unfortunately, I don't have any other ways to help you right now But I believe these slides will be available online And I know that our paper that goes with these slides will be available online following this presentation continuing on as you're defining a UOP Supplied model or USM You provide some additional information about the software threads that make use of your data model and You also define endpoints that have Message connections coming into and out of your unit of portability as Again was described earlier you can use then templates and queries which are part of the face standard to describe Contents of those messages when we have this level of detail describing a single software component and Its messages it sends and receives That gives us the ability to connect Show some parallels between the face standard and the AADL standard and doing that can allow us to put additional Information into our model that allows us to do more analysis. I Apologize to anyone whose Screen rendering doesn't show this in sufficient detail. What we're looking at here is a screenshot from SysML Which shows the Balsa example, which we've seen discussed in several other presentations today The Balsa example is a simple system That is composed of I believe five face units of portability and Here we see several of those specified here. I want to call your attention specifically to the ATC manager in the upper right-hand corner and I want you to take note that we have applied multiple stereotypes to this entity in Particular we have used a face unit of portability stereotype and an AADL thread group stereotype in doing so we have Defined a entity that is both a unit of portability in the face context and an AADL thread group in the AADL context So we can do our analysis both on sliced side for Excuse me both on the face side for face conformance testing and on the AADL side If we want to do behavior or performance testing on the same model entity That's a really important point. So I'm gonna let that sit for a second. So one more time what we've done here We have a single element in our SysML model and we applied stereotypes from two different languages and In doing so it allows us to have a single model that we can analyze using tools built for either language Going back to our initial starting point or our takeaways if you are Designing or coming up with a workflow for modeling. This is the kind of question you should think about Do you want to have individual entities? Stereotypes from different standards. Do you want to have translators between standards? There's no single answer. We're demonstrating one answer and this is something that's important to think about Early in your modeling process This is again just reiterating the application of AADL and face stereotypes again to the Balsa model Here we're showing data flows between ports Recall that part of the UOP Specification in the face data standard in the UOP supplied model includes specification of ports We can use those ports and optionally the face integration model that was added in face 3.0 To show connections between UOPs This is where sliced comes into play Then recall that the face standard does not give much information about behavior of UOPs However, the AADL standard allows you to provide Fairly detailed state machines describing the behavior of a software component sliced analysis tool uses the composition Of all of your unit support ability together with their behavior specifications To analyze the composed system behavior. We'll see an example of that Just a moment. I kind of stole my own thunder on the next slide But I'll say it again because it's a key takeaway here. So sliced lets you perform virtual integration of your unit support ability By combining them together in one model where you connect their messaging inputs and outputs and Then analyze their behaviors together. We accomplish that by using both the face standard and the AADL standard together We demonstrated this in magic draw sys ML using the face and AADL stereotypes. I Apologize again if the details of this are difficult to see but what we're looking at here is a sys ML state diagram For those of you who are familiar with balsa You may recognize these UOPs That are called out at the top of the screen and you'll note. We have several states Called out for each UOP in Particular starting from the upper left-hand corner. We have the air traffic controller manager Which has several states it can be in a done state a wait for configuration state or a wait for EGI state This is a slight variation on the typical use of a system L state diagram however, what it lets us do is it lets us render a Counter example to a correctness assertion about a system Or the user to see I'm going to jump back a couple slides to get to our reference problem Excuse me, so to arrive at that sequence diagram We start with this model of our composed system of units of portability For each unit of portability again unit of portability being the face concept We add a state diagram that uses concepts from the AADL We use sliced which is a Bentham's behavior analysis tool Analyze the combined behavior of all of these UOPs We analyze that combined behavior for heuristic based conditions Such as deadlock or live lock. That's a key point. So I'm just going to say it again Sliced analyzes the composed behavior of multiple UOPs for problem conditions Example problem conditions include deadlock and live lock both of which are states of either a UOP getting stuck Where it can't move at all. It's stuck in a state or a UOP that is spinning constantly and Unable to make progress. It's not technically stuck, but it is spinning We can also use this kind of behavior analysis to evaluate timing conditions such as a Latency condition that must be satisfied by a system. So with that in mind look back at this picture When sliced runs on a system composed of multiple UOPs It analyzes that system for potential error conditions If it finds a path of execution of the system for which an error condition is reached Sliced generates a counter example Then it renders that counter example as a CIS ML sequence diagram What we are seeing here is a auto-generated CIS ML sequence diagram showing as says at the very top of the screen an Assertion that the air traffic controller manager always reaches its final state has failed What that means is there is at least one path of execution in this system for which the air traffic controller manager does not reach a final state I've highlighted in boxes one and two the conditions that lead to this state particular what we see is the air traffic controller thread is not running or has not run in time and So the air traffic controller manager thread as shown in box two is stuck in the waiting state It is deadlocked waiting for input that it never receives Critical point here is we are analyzing all possible behaviors as specified in your model This is not a simulation. This is analysis of all possible behaviors as specified in your model the following workflows describe different ways you can apply The sliced and face modeling profiles in CIS ML For the sake of time since I see we have three minutes left and we've generally been relieving We've been leaving two minutes for questions. I'm going to blow through these fairly quickly the main point is that if you have existing models you can import them into your modeling environment or You can start from models that exist in one environment and add profiles on top of them And finally you can combine or translate models between representations The details of these are available in our paper However, for the sake of time, I'm going to wrap up now and bring you all the way back to the introductory takeaway comments that I started with Which was number one Think about all of the standards that need to be considered in your modeling environment It's not sufficient to just think about face or just think about host You need to think about the interactions between those standards how they overlap how they relate and Your plan for translating adapting or sharing between them number two That the face standard provides a data model interoperability framework But it does not provide extensive information about behavior of software That is to say there are integration errors that can arise that are unrelated to the face data model compatibility, but can still cause significant problems when you try to integrate UOPs sliced is a behavior analysis tool that Aims to discover those problems as early as possible in the modeling and design process Thank you very much and now we'll be open for questions Thanks, Tyler. We do have one question, which I think you probably can see From Sarah you are saying state diagram, but showing an interaction in parentheses sequence diagram Do you mean state or interaction? Yes, sorry about that Sarah We specify the input to the sliced behavior analysis via sys ML state diagram sliced generates a sys ML sequence diagram or interaction diagram in This slide deck. I did not include the Specification of the state diagram. We actually have four different state diagrams one for each UOP. I Am happy to share those or discuss those offline But I did not include screenshots of those in this talk. Okay. She said thank you for the clarification One other question. Does slice provide a qualified co-generation from behavioral models? Slice does not one of the design decisions that we made in developing sliced Was that we wanted to use state machines at a level of fidelity consistent with the level of fidelity of the face usm face does not Require vendors to provide details on the internal implementation of their unit support ability and Slice takes a similar approach. We do not require those type of internal details and As such slice does not have enough information in its models to generate code sliced is about analyzing your design at the level of the UOP interface such that you have a state model you could share with a Vendor or with an integrator without revealing proprietary design information You