I'm Steve Nunn, President and CEO of the Open Group. Welcome to Toolkit Tuesday, where we highlight the various components and leading experts of the Architects Toolkit, a collated portfolio of the most pertinent technology standards for enterprise architects. During the series, I'll be calling on a number of recognized experts who will bring their particular insights on how to most effectively use the various tools in the Architects Toolkit. We'll have a mix of interviews, panel sessions, and pre-recorded presentations along the way. While all standards of the Open Group are designed so they can be adopted independently of one another, the greatest value for an organization can be derived when they're used in unison, that some of the parts should be greater than the whole. In the Architects Toolkit, we have collated a portfolio of the most pertinent ones for architects, together, all in one place. For most of these tools, certification from the Open Group is also available, so practitioners can demonstrate that they have the skills required, and recruiters can take the guesswork out of the recruitment process, all backed up by our Open Badges program. So, architecture is all about gaps. What do I mean by that? Well, we, as architects, catalogue and we model what is there and what we want to be there in the future, and then we concern ourselves with finding the gaps between the two so that we can fill them in. Musicians play the rest as well as the notes. That's what provides rhythm. Actors deliver the dramatic pauses between the words. That's what provides the flow. As architects, what are our rests and pauses? Is that space in our catalogue or our model an intended void, i.e. a rest between the notes that we need to keep empty and preserved, or is it a gap somewhere that we need to fill in with notes and or more rests, maybe, before we can perform and execute it? So, to me, that says we should look at architecture spaces and consider whether they are voids or gaps. Welcome to Season 2 of Toolkit Tuesday, everybody. My thanks to Paul Holman there, of IBM, for his intro on EA Minute, Architecture Spaces. I'm thoughtful as ever. Thank you, Paul. Say a little bit more about Paul and the EA Minutes in a moment, but I really want to welcome everyone to Toolkit Tuesday. We had a little break over the northern hemisphere summer. Anyway, many of you are not in that hemisphere, but had a little break for a while. We're back and glad to be back, and we have a great season ahead for you. And my purpose today is really to give a little recap or a refresh of some of the topics that we covered in Season 1 and remind you where you can get them if you missed them or you were there live, but never went back to see the recording. So I'll do some of that.  Please stay tuned and ready for that. We love to see where you are joining us from. It's usually a number of countries that's into the 20s at least when we have one of these, and it's great to have people joining at all different times a day or night and from all over the world. And it's one of the things that makes this special. So without further ado, I'm going to run on to what I said I'd do is a quick recap on Season 1. And looking back on it, can you believe we had 21 episodes of Talk It Tuesday? We had a few planned when we started and thought, well, let's see how this goes. The response has been really, really fantastic. Very enthusiastic reception. And as a consequence, we've kept it going and here we are for Season 2. We made it through our dreaded first season and will we be brought back? Well, yes we are. We're here. And many of those episodes, just like today's, started with a video, a short video. It was either one of Terry's Talk It Tuesday tips from Terry Blevins or one of Paul's EA minutes. So unfortunately, we've lost Terry Blevins from our panel of experts as he's now enjoying a very well-deserved retirement. Terry was a very long-term contributor to the open group and in fact, many of you may not know this, but he was one of the very first small group of individuals who got together to work on what became the TOGAF standard. So we all owe Terry and his peers a great debt on that. So we won't be seeing Terry's Talk It Tuesday tips, but we will be. The good news is we will be having more of Paul's EA minutes and delighted to have those. And you'll hopefully have just seen the first one on architecture spaces. So we'll have a few more of those from Paul over the course of Season 2. One of the things we've had is to try to keep a bench or a panel of resident experts and Paul will continue to be on that. We've had Chris Frost of Fujitsu who will still be around and also my colleagues, Andrew Josie, Chris Ford and Sonia Gonzalez from the open group. They've all been part of the Ask the Expert session, which is one I think will recap or come back to, I should say, in Season 2, as well as a Q&A session. It's a good way of cycling back to some of the great questions that we don't always get time to in each episode. We try to limit the episode to 30 to 32 minutes maximum just to respect everyone's time and it doesn't always allow us to get to all the questions. So sometimes we cycle back during the season and have a session that's just dedicated to answering those questions. So I think you can expect to see that. As I said, we've had a lot of great feedback on the show on Season 1 and we love it. Please, it comes through through the chat channel. It's often when people are leaving, they give a brief comment and that's all we're really looking for, but it's great to do that if you have the chance before you leave any episode that you're on. Just leave us a few words. We collect it and we do read it all and it's valuable to us. And at some point we'll set up a more formal way of asking you for topics that you might want to see covered on Toolkit Tuesday. Anything that's particularly important or of interest to you, either as an EA practitioner or as somebody interested in the field, we'd love to get those. So if you have any of you on today, you have any then maybe put those in the Q&A channel and we can make note of those. But we'll set something up so that you can have an opportunity or a vehicle to suggest some additional topics for us. So what did we cover? Well, unsurprisingly, given that this is the Open Group Toolkit Tuesday, we covered a number of TOGAF standard related topics. We had EA Enterprise Agility with the TOGAF standard. We had a look at the TOGAF series guide on microservices architecture, principles for an EA framework and the importance of adopting the TOGAF standard. Several of those episodes and they were always very well attended with a lot of questions. And of course, near the end of season one, we had the exciting news of the release of the TOGAF standard 10th edition with a summary of what's new and different in that. And on that note, we have something interesting to share with you later as I hinted earlier, so we'll get to that shortly. Other topics we covered. Another sort of bucket, if you like, of putting the sessions into was the topic of digital transformation. I mean, that's who isn't concerned with that right now. And we will be for some time to come, I suspect. But we covered it in a number of ways, how to use the Open Group Architects Toolkit and our portfolio of digital open standards in supporting digital transformation. We covered both of those. We had a run through of the seven levers or the seven levers, depending on where you are in the world, of digital transformation, which is still one of my favourite white papers that we've published. A really great introduction to the kinds of things that you have to think through during digital transformation. Modelling. Some of you and a lot of people out there in the world are interested in modelling. And we covered that in a couple of ways. We looked at how to use modelling for strategic decision making and real examples of using the Open Group Archimake Modelling Language, actually for real. That was a popular one too. As well as a session, not directly on modelling, we had a session on automating analytics with EA Road Maps and the use of tools. And one of our most well attended sessions, which was a slight surprise to me, not because I knew the speaker and the content wouldn't be great, but I didn't realise the subject matter would be quite so popular, was how to develop a MOSA or a modular open system architecture, reference architecture. That was a great session. And we had quite a bit of interest in our data integration toolkit and public digital platforms. And we also had a session that caused a lot of follow up and questions afterwards on our EA Academic Initiative in India called the Initiate Program. And you can find out more about that and many of these things on the Open Group website. And we covered actionable supply chain security as well, some real life lessons. One of the things that goes through many of these sessions and many of the topics when we have a longer event at the Open Group is the idea that what people want is case studies. What has worked well, what hasn't worked so well and how can we learn from the great decisions or the temporary mistakes of others? So we try and include as many of those as we can. And kind of the final bucket, if you like, of topics that we covered was and it's something that's dear to our hearts here at the Open Group is the topic of professional development. So we looked at, we had a topic on the future of architects and innovation and digital transformation. And also an introduction to the Open Agile Architecture Certification. So different from Togaf aimed at a different use but works very well when used in conjunction with the Togaf standard. And of course, we started actually with a guide to the Open Group Library which is where you can find all this great stuff that we talk about. And within the Open Group Library is the Togaf Library and that was a useful guide through that to make finding it as easy as possible. And don't forget that the sessions that we've had so far they're all available on the Open Group YouTube channel and you can also get to them from our website. And so as far as season one is concerned I'll repeat my thanks to all our presenters and experts in season one but to most of all any of you who attended any of you here today who were in attendance for season one thank you. And we've been delighted with the levels of participation and the great questions. So long may it continue. So looking forward now to season two what can you expect? Well among the topics planned we have EA and Blockchain in fact that's the next one that will be two weeks today. EA and Blockchain. We also are going to cover Zero Trust Architecture which is a topic that we played a big part in our last in-person event at the Open Group in July and we'll get information on an overview of updates to the Archimake standard and the significant progress that's being made on the Open Group portfolio of digital open standards. More on digital transformation and the role that EA plays within it of course. Some highlights from our Togaf user groups and inevitably due to the level of demand more Togaf standard related content. So on that note let me move to today's topic and this isn't intended to be a deep dive into the topic it's more of a teaser but the topic is really our latest approach to Togaf standard certification and you may recall that when we published the standard the Togaf standard 10th edition of April we promised updates to our certification program in the coming months and we've made quite a bit of progress on that front and here today to give you a brief look into our thinking is my colleague the Open Group vice president of standards and certification Andrew Josie. Andrew are you there? There you are, right on cue. So you open season one the first episode of season one with the library and here you are on the first episode of season two so there's a theme here. So what can you share with us today about Togaf certification? Okay Steve, I've prepared a few slides so let's just see if I can get those sharing okay. Hopefully you're seeing the right set of slides. Looks good. Yeah. Okay, so thanks again Steve for that introduction it's good to be back again I'm going to say always a series opener that's my lineup that's what I do. As you know we released the Togaf standard 10th edition in April this year it's obviously times blown by a little bit but some of you may be familiar with this diagram from the 10th edition website. I want to spend a few minutes just thinking about our approach to certification so this is the if you can see the diagram there it's sort of in the get certified area I'm going to be talking about this in a lot more detail at the open group Edinburgh event so a little plug for the event there. As we highlight on this diagram what we see with the Togaf standard 10th edition is a refreshed modular structure and that makes it much easier to apply the Togaf framework to different kinds of organizations and also styles of architecture. This is the set of documents that we released in April as you see it's quite a large set we have six what we call the Togaf fundamental content documents that are in the bottom sort of left after this screen and 20 Togaf series guides. We actually expect this set to grow over time this set can be and has been packaged in a number of ways so you'll see that we've got the digital edition we have PDF downloads and we also have the hard copy so just show you a quick glimpse of the hard copy for the hard copy obviously we decided we couldn't print you know all 20, 26 of the current documents so we selected I think it was about 15 documents packaged them into actual sort of again little subsets and we published seven hard copy documents. Now with such a breadth of available material we've had to consider how best to manage that for our training and certification purposes so the approach that we've actually decided on is to define a number of bodies of knowledge drawn from the standard. What do I mean by body of knowledge? Well a body of knowledge is something that defines the content for a certification and a body of knowledge is something that defines what is examinable so you know what will be the topics for the exam. So where does this lead us? So for the Togaf standard 10th edition we're going to be defining multiple bodies of knowledge each of them related to a specific skill set or competency drawn for the standard so this will lead to multiple certifications and certification credentials being available. It will also allow us to have a stable and targeted certifications and permit the standard to grow because we expect the standard to continue growing and this will include new learning paths both for people who are coming to the certification program for the first time but also those who are Togaf 9th certified. And where can you find out more? As I say I'll be talking at the Open Group Edinburgh event in October. I hope you'll join us to find out a little bit more well in fact a lot more about this then. Back to you Steve. Andrew it's great thank you very much for that whistle-stop guide to the thinking behind certification so as I said before and it's not intended to be a deep dive today it's really welling people's appetites for hearing more in a few weeks time at our Edinburgh event but obviously unsurprisingly the questions that come in are around there's a lot of interest let's say in what we're going to do with certification so if I am Togaf 9th certified will there be a way to is the question I know that we've had before and answer before but will there be a direct way of upgrading my certification? Yes Steve there will be a number of ways in fact for those people who are Togaf 9th certified who want to sort of refresh and update to the latest equivalent certification there will be what we call a bridging path so there is a bridging syllabus that will be being defined and there will be a bridging exam that you can take to qualify for that there will also be a number of other learning paths because as I mentioned there's going to be more than one certification there will be multiple certifications also what we call certification credentials which are actually smaller chunks of your learning so we've looked at the new standard and we've been able to define some new areas specific skill sets specific competences that we want to address and if you've got Togaf 9th certification you can recognize that as one of the prerequisites to come into those new learning paths that we're defining so basically if you're thinking about doing Togaf 9th certification right now it's a good move carry on do that and there will be upward paths for you as we expand what we're calling the Togaf certification portfolio to encompass also the 10th edition standard You answered the second question before me asking it which was you know I'm part way through studying and now I have to so yes go ahead it's always been our message do go ahead with the Togaf 9th certification that's going to still be worthwhile and the structure of the new the new program will be will be quite different but you'll be easy to see where your path or choice of paths will be that's great and another question that's come in Andrew which I know you can answer this easily is how can we download the Togaf 10 document series OK if you just either go to the open group site and I think on the right that says the Togaf standard 10th edition is available and you just follow the links but where you will end up in is the open group library look for Togaf in there and there was also a link on your slide I noticed earlier there was the digital edition go to I think it's www.opengroup.org Togaf 10th edition although I can't spell that quite as I think it's 10th edition I think that's the URL it's right to follow great stuff well Andrew we'll leave it there for now as I say you'll have triggered some interest and you'll hear more about where we're going with certification at our Edinburgh event which is coming up quite soon next month it's I'll give a shameless plug Andrew give a slight hint but a shameless plug I'll give it's October the 17th to the 19th at the Edinburgh International Conference Centre and we also have a conference hotel which is the Sheraton Grant Hotel and Spa so there are some quite a few of the people attending will be staying there but not obligatory but yes the Edinburgh International Conference Centre is the venue our main theme for the event this is basically over three days but our main theme is EA and sustainability and digital open standards so those are the main themes crossing the three days we'll also along the way have a Tegaf user group and an open professions workshop open professions is a program in the open group certification program a lot of people know about the knowledge based programs like Tegaf, Archimede, IT for IT, OAA etc but the open professions is more of a skills and experience based program and we'll be having a workshop about that and I think we can expect a session on that at future Toolkit Tuesday too because it's something that as people learn about it they tend to be very interested in from a professional and personal development point of view we also have meetings in Edinburgh for our architecture forum our Archimate Forum IT for IT forum and the digital practitioner work group so if any of you are members your organizations are members of the open group and our members of those forums then it's be a great opportunity to meet in person with your peers in those forums and we'll have some great speakers from our open footprint forum as I say EA and sustainability is one of the main topics and we'll have some really great speakers speaking on the topic of sustainability which is something that we're all obviously coming across every day and needing to find some answers for so the registration information is available on our website in fact we've never done this before but a very special offer today the first person who is attending Toolkit Tuesday today who signs up for our Edinburgh event using the special Toolkit Tuesday code which I hope will appear or has appeared in the chat sign up using that code and you'll get a free pass to the event I realize that some of you attending it's a long way away and there'll be more local events for you in the future but if anyone was on the fence thinking about it make sure that the first one registered and you'll get a free pass to the event and I should say as well not something we do very often but every few years or so usually in Scotland in fact always in Scotland we're hosting the open group golf event today which is at the Torrance course in St Andrews so if that clinches the deal for anyone thinking of attending the event then please do join us we have limited spaces but we do still have a few available for that and that's on the Sunday before the event so that's really it for today's topic and talking about certification and you will hear more obviously as you've as you've gathered in the coming well next month at our Edinburgh event and I'm sure at some point we'll hold more detailed sessions on this in Toolkit Tuesday in the future but for now that's it for today's topic don't go away just yet though next time around we will have a great session it will be Rick Ross who is the director of consulting blockchain emerging technology at EY and our very own Jim Hitella the open group vice president of business development and security they're going to be exploring the intersection of blockchain and enterprise architecture and that will serve as a kickoff for actually a whole webcast series on the topic various topics relating to the use of VA in different blockchain use cases so if you want to know what blockchain is all about if you know already and want to know more see you in two weeks time meanwhile thank you for joining us on our first episode back for season 2 of Toolkit Tuesday I'm Steve Nunn thank you for watching


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


One of the most common fears patients express when facing surgery is postoperative nausea, which ranges from minor queasiness to protracted periods of vomiting. Feeling sick to one's stomach and throwing up after surgery is a common problem, affecting between a quarter and a half of those placed under general anesthesia. And more than half of those at high risk. Who's at high risk? Women who don't smoke and have a history of motion sickness. I've explored the science behind treating nausea with ginger, but if you're too nauseous to eat, what do you do? Well, people are often sent home with anti-nausea rectal suppositories. However, surveys show that cultural and sexual attitudes may make a number of people sensitive to anything involving the rectum. But the wording of the survey question they asked was, are you happy to have a drug put up your back passage? And I can imagine many of the respondents thinking, well, maybe I wouldn't mind so much, but wouldn't exactly be happy about it, especially when you're feeling sick and throwing up. And for women after a C-section, they might not want to take drugs regardless of the orifice if they're breastfeeding. So, researchers decided to put aromatherapy to the test. Research has shown that essential oils of both spearmint and peppermint are effective in reducing nausea and vomiting after chemotherapy. But this was after taking them internally, swallowing them. Would just the smell of peppermint help with nausea? Did women take deep whiffs of peppermint extract, like you'd buy at the store, and it seemed to work? While non-sniffing plain water with green food coloring, the placebo, and none in the control group who didn't sniff anything, none of them felt better. 80% of the mint sniffers felt better within just a few minutes. Now, the study was criticized for being small and for not using pure peppermint oil. Peppermint extract is peppermint oil plus alcohol. Maybe it was just the smell of alcohol that made people feel better. And that's actually not too much of a stretch. In 1997, researchers reported a simple, innocuous, and inexpensive treatment for post-operative nausea and vomiting. The smell of isopropyl alcohol, which is what's found in those alcohol wipes, the little prep pads that nurses swab you with before your shots. They found out that they could just effectively tear one open, wave it under someone's nose, and relieve nausea and vomiting more than 80% of folks after surgery. It's been since shown to work as well as a leading anti-nausea drug, and may even work faster, cutting nausea in half within 10 to 15 minutes rather than 20 or 25. So, was it the alcohol, the peppermint, or both? We didn't know until it was put to the test. Patients were instructed to take three slow, deep breaths, inhaling through their nose, exhaling through their mouth, smelling alcohol, peppermint, or nothing. The smell of the peppermint cut nausea in half within five minutes, and so did the alcohol. But so did smelling nothing. So maybe it had nothing to do with the scent. Maybe it was just the instruction to take slow, deep breaths. That would make it a really cost-effective intervention. If all we have to do is tell people how to breathe, though maybe it shouldn't be so surprising given the proximity of the vomiting and breathing centers within our brain. And indeed, controlled breathing was effective with or without any scent. So next time you feel nauseous, inhale deeply through your nose to the count of three, hold your breath to the count of three, and then exhale out the mouth to the count of three, and do that three times. Ironically, the researchers continued to advocate using that nasty-smelling alcohol pad even though they showed it wasn't any more effective than breathing alone. Why would they do that? Because since isopropyl alcohol has a readily detectable odor, patients are more likely to think that their postoperative nausea vomiting is being actively treated when they inhale alcohol vapors rather than just engaging in breathing exercises.


Thanks, thanks, Ming. Hi everyone. So the problem that we're focusing on is one which we think keeps smart contracts limited to tokenization, right? If the native functionality you have when you start working with a smart contract network is the ability to make tokens, that's the functionality you'll start working with and you'll do a lot of interesting things with it. But the capabilities of smart contracts go far beyond tokenization, there's enough logic to mimic and eventually replace the majority of digital financial agreements. Those agreements as they're structured will need triggering events, so they'll need inputs into the application and they also need to have outputs as a form of payment, right? So in our opinion one of the very large limiting factors for the creation of interesting real-world use case smart contracts is their ability to step beyond tokens and interact with external inputs and external outputs in a meaningful manner, right? So the approach to solving that problem is basically middleware. You create a piece of middleware that takes the external inputs, turns them into something that the contract on-chain can interact with and you have the middleware provide those inputs to the contract, those inputs can be any kind of data feed, the IoT input about delivery, any input that application needs. Likewise the middleware can provide outputs into relevant payment systems. Now, right now there isn't a large amount of these capabilities and the parallel I tend to draw on my mind is in the web development world when you want to build an application you have a ton of APIs you can connect to a contract, right? In the smart contract development world right now due to the lack of on-chain contracts that represent off-chain resources it's very difficult for a smart contract developer to get access to the inputs and the outputs they need to make an application, right? Like the people that made Uber or any number of other web applications, they put a GPS API, any number of other APIs together with their core application and then they had a payments output in a payments API, right? It should be just that easy for a smart contract developer to take inputs, combine them with their core application in the form of a smart contract and then have that smart contract make the relevant outputs without them figuring out how to make that connectivity work at a very deep level, right? That's what blockchain middleware as a general solution provides, right? The benefit of blockchain middleware for a smart contract ideally would be that it maintains the same level of security as the contract, right? You don't want a contract that's highly secure, that's triggered by a highly insecure system and that pays out through another highly insecure system. If you have a very secure middle part of the end-to-end setup and the inputs and the outputs are insecure it's unlikely that digital financial agreements of large value are going to transfer from the legacy world into the smart contract world, right? So as a community or at least we as a group of people are very interested in solving this problem of how do you get a smart contract to do something meaningful relative to the real world but also to do it so securely that the input of the data that triggers the contract, the contract itself and the output can all be trusted at a very high level of tamper-proofness. So to understand what our options are in this problem it's good to look at like what is some of the current approaches. One very common approach is basically the use of a centralized oracle. So that is the approach where either an individual in the contract runs an oracle, one of the counterparties or possibly a service. In any case there's a single centralized oracle that acquires data as a trusted third-party and gives that data to the decentralized computation network to process it, right? The problem with this in our opinion is that the decentralized computation network has thousands of nodes which provide the tamper-proofness and the security guarantees we all value in that contract while the centralized oracle triggering this highly tamper-proof decentralized computation is not tamper-proof, right? So the setup end-to-end at this point is not tamper-proof. It's not going to appear very secure. It doesn't provide the tamper-proof guarantees that we think are important for smart contracts to have a unique value, right? And so this attack vector of how do you attack a contract that has one node triggering the key events is the attack vector that we think is worth seriously considering everything from DevOps problems with that one node to somebody genuinely attacking a single node to stop a contract from running on, you know, could be a million nodes. It doesn't matter how many nodes are in the decentralized computation environment if the trigger is attacked and compromised and doesn't happen the contract won't trigger. So the approach that we advocate to this problem is two-fold. The first part of it is decentralization. So we apply the idea of decentralization to oracles to blockchain middleware and we create an oracle network that is able to process and acquire the data using multiple independent node operators. Those independent node operators can be selected by the person making the contract and they can select as many node operators as they want two, five, ten, fifty, a hundred. However much decentralization they want at this level of middleware they can now acquire to give them guarantees about tamper proofness in terms of their inputs. This ability to decentralize the blockchain middleware layer, the oracle layer, also gives you the ability to now contract with multiple data sources. In our opinion, it doesn't make as much sense for one node to use five data sources. You centralize the data at the level of the origin but it's still going through one point of failure. Now once you have, for example, five separate decentralized oracles, they can all acquire data from five separate data sources. If that's something that your use case needs. So there's going to be an entire spectrum of use cases that do and don't need this but in our opinion the high value use cases are going to want to provide a high level of tamper proofness through decentralization which is what we'd like to enable so that the end-to-end setup is sufficiently secure for people to trust it to put actual money into a smart contract for things to go to production. The other part of our approach is that it's open source and we believe very strongly in open source and security reviews through open source both on the level of the on-chain contracts and the off-chain implementation of the middleware and we believe that a shared large community of people working towards a blockchain middleware that can solve this problem will make a blockchain middleware that payments processors, data providers, e-signature providers, various API services will adopt because they don't want to build their own middleware. They just want to sell their services and they constantly buy things that just let them sell their services. So what we should do in our opinion is that if we as a community are interested in this problem we should solve it in the centralized manner that allows the people with the data resources, payment resources, e-signature resources, various other APIs to be able to provide those services to contracts so those contracts can then do something much more meaningful. Now the second part of our approach after decentralization in open source is the application of trusted hardware. So trusted hardware provides certain tamper-proofness guarantees. In this case applied to oracles, those guarantees extend as far as the node operator will not know what they are running, the node operator will not be able to tamper with the data, the node operator will really only be able to turn off their node and that will be an immediate signal and with even basic reputation systems they won't participate in future inputs into high value contracts. So the application of trusted hardware and its new recently evolved form in terms of Intel SGX is something we think has a lot of merit and is an approach that can create a decentralized oracle network where you can sufficiently trust the independent node operators to execute the acquisition of data and the execution of payments while not knowing important things like your payment credentials or what data they're executing. Another very large benefit is the ability for you to do off-chain computation in this same oracle network. So the oracle network can now become a layer of off-chain computation around the data it acquired for intensive computations that you can't or don't want to do on-chain. So to dive a little deeper into trusted hardware and why we think it's an interesting approach, the main premise on underlying trusted hardware is that compared to previous approaches like various HSMs, various data rights management modules, it has a smaller trusted computing base. So what that means is that privileged system code like the OS and BIOS are no longer attack vectors for something like an Intel SGX enclave. What that means is that you can give even encrypted code into the enclave and it can decrypt it and run and make outputs and the operator of the node running something like Intel SGX can't tell what's going on, they can't acquire private information and once again all they can really do is turn it off which becomes immediately apparent. Now the approach that we're adopting towards trusted hardware in the context of a decentralized oracle network with the help of the very smart folks at IC3 who we're very lucky to be working with is called Town Crier. Town Crier basically applies Intel SGX which at this moment appears to be the leading trusted hardware approach to the problem of secure tamper proof oracles. It basically allows a contract to talk to an SGX enclave that then using the existing TLS scheme can acquire data from a data source and then provably return only the value that it acquired from the enclave into the requesting contract. In this case the requesting contract is the Town Crier contract which then kind of is the on-chain bridge from the enclave into the user contract. It's a very common oracle setup but the difference is that the enclave provides this tamper proof guarantee. In our opinion when you look at how do we make smart contracts useful? What is their unique value? It's the fact that they're tamper proof, tamper resistant, kind of these unstoppable financial agreements and as tamper proof as we can make something like the triggers of those agreements is probably the right direction to go in and those two approaches once again one is decentralization and the other one is the application of trusted hardware. Now how this would look if trusted hardware works and everything works out properly is that a user shows up and says I have a very large computation that needs data. I'm going to give that computation into the the relevant node. The relevant node is going to take that computation and run it in the enclave inside an EVM right so there'll be an EVM running inside the enclave the EVM will run the computation and it'll run it privately such that even the node operator can't acquire the data. If and then they'll return a query ID the query ID is what's used to pay the contract and it returns relevant information for payment. After that what happens is let's say one of the counterparties wants to know what is this oracle doing? What is this decentralized oracle network or this set of oracles that is that are going to trigger the agreement that I'm a part of? What actions are they actually going to take? Can you please return to me the code that you're going to execute at time X? At that point the counterparty in this case Bob receives back an encrypted blob which he can decrypt because he has the relevant private key. So in this scenario what's been done is that the creator of a smart contract has written in oracle instructions in this case in solidity so they've written oracle instructions in in a format they're already used to working with that that compiles down to EVM bytecode. They've put those oracle instructions into the the enclave. They've set it up to trigger their contract without the node operator knowing. They've done this with anywhere from 5, 10, 15, 20 individual node operators so that if one fails or if one is attacked it doesn't it doesn't compromise the execution of the contract and then they've done it in such a way that if their counterparty wants to know what is the oracle setup we're using going to do at time X let me randomly check that anytime I would like they can go submit the query ID and receive both the encrypted blob and then attestation from the enclave proving to them that the execution that is supposed to happen at time X is is going to happen right. So at this point we we have multiple node operators executing a valuable off-chain operation and we have them being able to prove it to the other parties in the transaction. The the benefits of this approach in our opinion are basically that you can have very scalable execution off-chain. You can put whatever well not anything but but definitely much more much more intensive computations into SGX and very possibly things you would never want to be public given under certain conditions of encryption or other things. Due to the privacy of SGX you can basically acquire some amount of surety that the node operator that you've given the code to hasn't hasn't acquired it and you can also do very interesting things such as have smart contracts control private keys. So how we think this is going to evolve is that you're going to write one big one smart contract in in two parts right you're gonna have an off-chain part both of them written solidity you're gonna have an off-chain part the off-chain part is gonna is gonna make all kinds of off-chain requests that will look like this and require all kinds of computations. You're gonna write it in solidity or whatever language you'd like that goes down to EVM bytecode. You're going to run it into an SGX enclave and then that SGX enclave will have capabilities such as the control of a private key or the ability for the SGX enclave to make a direct request to a native OS library for something as useful as randomness right. So the thinking here is that you don't learn a new language for oracles or anything super specific you continue writing in the language that you're writing your contract in but you have an off-chain portion the off-chain portion relates to your acquisition of data and your computation around that data and then the on-chain portion is what you have on-chain that is presumably triggered by that on-chain data but by the off-chain data that that reaches it and then presumably you have another section to the contract where you have off-chain payments where you want the contract to send some kind of payment message to a payment network or a bank or any other system that has their own blockchain middleware that represents their services right and then also if you want if you want key resources such as randomness or any other number of resources that can be provided from a native OS library that's been widely used and tested you can acquire it by directly messaging within the enclave so there's there's entire subsets of of what your off-chain computation can have within the enclave by having it message something like a native OS library from randomness eliminating certain scenarios where you would ever need to use a service and you kind of get the tamper proof guarantees both on the level of the data acquisition and also on the level of this native OS library once again also very possibly run in multiple nodes and those nodes being able to come to decentralized consensus about about the execution of of of that computation and even the acquisition of randomness now the the reason we're we're kind of applying this level of stringent security and tamper proofness is that the world we'd like to be in in a year or two years relatively soon is is the ability for a contract to reach out to another contract on chain and for that on-chain contract to represent an off-chain resource so that a smart contract developer no longer needs to learn APIs they have an entire list of contracts on chain which we call chain links but you know are basically oracles that represent every type of data off-chain payment mechanism e-signature basically any any web service that a web developer gets access to to build their application is a service that a smart contract developer should be able to get access to from a contract on chain and and that's the that's the quick prototyping world we want to be in for people to build killer applications of smart contracts by focusing on their core application and getting all the inputs and outputs they need while making sure that those inputs and outputs are sufficiently secure that their end users the other parties in the agreement trust that the source of the inputs the method of input the contract itself the method of the output is is sufficiently secure to trust that end-to-end setup right the the world we want to avoid is one where you have a highly secure decentralized computation that is then triggered by highly insecure services which once looked at lead people to not put any real value in the contract right that's the world we want to get away from and the the world of secure end-to-end smart contracts is the world we'd like to approach if you'd like to know more you can find the technical details in these two papers and we're always happy to to discuss this and we're also working on this in an open-source manner and looking for for interested folks to join us to solve this problem so thank you