Industrial Talk is onsite at the OMG Quarterly Standards Meeting and chatting with Sandy Friedenthal and Ed Seidewitz about “The next-generation System Modeling Language (SysML v2)”. Tune in and hear more about the importance of the latest in SysML v2 and Sandy and Ed's unique insights on this Industrial Talk.
Finally, get your exclusive free access to the Industrial Academy and a series on “Why You Need To Podcast” for Greater Success in 2023. All links designed for keeping you current in this rapidly changing Industrial Market. Learn! Grow! Enjoy!
SANDY FRIEDENTHAL'S CONTACT INFORMATION:
ED SEIDEWITZ'S CONTACT INFORMATION:
Personal LinkedIn: https://www.linkedin.com/in/seidewitz/
Company LinkedIn: https://www.linkedin.com/company/model-driven-solutions/
Company Website: http://www.modeldriven.com/
THE STRATEGIC REASON “WHY YOU NEED TO PODCAST”:
OTHER GREAT INDUSTRIAL RESOURCES:
Arduino Pro: https://www.arduino.cc/pro/
Hitachi Vantara: https://www.hitachivantara.com/en-us/home.html
CAP Logistics: https://www.caplogistics.com/
Saviant Consulting: https://www.saviantconsulting.com/
Industrial Marketing Solutions: https://industrialtalk.com/industrial-marketing/
Industrial Academy: https://industrialtalk.com/industrial-academy/
Industrial Dojo: https://industrialtalk.com/industrial_dojo/
We the 15: https://www.wethe15.org/
YOUR INDUSTRIAL DIGITAL TOOLBOX:
LifterLMS: Get One Month Free for $1 – https://lifterlms.com/
Active Campaign: Active Campaign Link
Social Jukebox: https://www.socialjukebox.com/
Industrial Academy (One Month Free Access And One Free License For Future Industrial Leader):
Business Beatitude the Book
Do you desire a more joy-filled, deeply-enduring sense of accomplishment and success? Live your business the way you want to live with the BUSINESS BEATITUDES…The Bridge connecting sacrifice to success. YOU NEED THE BUSINESS BEATITUDES!
TAP INTO YOUR INDUSTRIAL SOUL, RESERVE YOUR COPY NOW! BE BOLD. BE BRAVE. DARE GREATLY AND CHANGE THE WORLD. GET THE BUSINESS BEATITUDES!
standard, system, omg, modeling, tool, sandy, language, talk, vendors, specification, engineer, information, involved, engineering, developing, Edie, people, ed, interfaces, build
Welcome to the industrial talk podcast with Scott MacKenzie. Scott is a passionate industry professional dedicated to transferring cutting-edge industry focused innovations and trends while highlighting the men and women who keep the world moving. So put on your hard hat, grab your work boots, and let's get right once
again, thank you very much for joining industrial talk a platform once again, dedicated to you industrial professionals all around the world because you are bold, brave, you're daring greatly. And I am changing my life and you're changing the lives around the world. You're making the world a better place. That's why we celebrate you on this. This podcast, you are the heroes in my story. That's what it is sort of creepy, but it is what it is. All right, we're broadcasting from where we are. Austin, there you go. Very safe. Step right. And right there. Austin, Texas. This is the fourth quarter of OMG. Right? This is the standards. This is where you guys sort of debate and do all the stuff that you need to do because you're smarter than I am. All right, you can tell I'm already using them. Sandy and Ed in the hotseat, they're going to be talking a little bit about what they're doing here. And much, much more. Let's get cracking. Thank you. Thanks for what you do. As a cool come.
Right. Great to be here.
It's Pleasure is all well, on this side of the trade here. It's it's this table. You guys having a good? I mean, it's just a one. Day one. Yeah, we that's not bad
luck. And really starting tomorrow. We're transitioning today, you know what,
you know what I want to say? I want to see those heated debates about, you know, things in the standard that you guys want to have. That's what I want. That's what I want to say.
We join in, anywhere that comes the reality is, is
that no, I can't join in. I'll just sort of sit there with popcorn and just sort of take it in and like, yeah, that's a good point. And that's a good point, I wouldn't be able to add any
reality is were mostly pretty boring.
Oh, no, no, you're not. I'm gonna just have to, you know, put a kibosh on that one, because you're not because I love what you guys do. All right, for the listeners. For the listeners, give us a little background on to you, Sandy, and then we're going to jump to Edie.
So I spent my career in aerospace and defense system engineering. Most of my career, I retired back in 2010, and started a small consulting company been involved with the OMG. Since I think 2001. Actually, number nine. So my first meeting we were talking about last night was around September 11. That's in Toronto. Yeah, yes. So, and I was involved and helped lead the effort for developing the system modeling language to smell v one. And now I'm involved with Edie and we co lead the effort to develop system L V two, which is the next generation system modeling.
All right. All right, Ed.
I also actually started in aerospace, but relatively early in my career, I moved primarily to information technology and software across a number of different domains also got involved early in doing modeling for software, and then in developing modeling languages. So, I was involved with the Unified Modeling Language standardization. From very early on, in fact, my first OMG meeting was 1999 So actually been longer than Sandy. So, I was heavily involved in developing modeling languages over the period here at OMG and applying them out in industry and got involved with Sandy in some extent and system lb one and especially when we started system OB two on the side of actually creating the language to support the kind of system engineering the Sandy's been doing for years. So,
for the listeners out there and the lack of acronym, you know, definition SysML V1 one, what is that
system ML V one system L is the system modeling language. And V one was the initial version that came out in 2006. And we are approaching the final submission to the OMG. Plan for the first quarter of next year for this next generation. system modeling language. FY two.
There you go. Okay, that that answers the question. All right. I have to ask this clarification, right. Sandy and Ed, do you guys work together? I mean,
we're caught Procol colleagues through this. This activity and we're friends
are there you go. And most of the time that works together.
Yeah. Maybe not in that order. Right. All right. You're here at this event in Austin, Texas. And tell us why this is important. What's what's why is this An important sort of meeting to have.
Well, the old GE has his quarterly meetings, and it was really interesting. They actually used to in the past meet more often. But over many years, it's settled down to having the quarterly meetings. And of course, during the pandemic, they went virtual. And it was interesting. Once we started coming back after the pandemic, the first one was December of last year, everybody was so happy to get together again, even though we're all professionals that actually do most of our work remotely, to actually figure out how to come together and form a consensus to build the standard. It always helps to get together with face to face meetings. So all what goes on in these meetings, and just to consolidate what we've been doing in between the meetings. And then some point soon, Sandy's said, we're moving towards the final submission, actually submitting our proposal on G formally, and then it starts going through the formal process of voting, and we need to make the presentation here. So having these actual physical meetings, and having the ability to get together in the groups here is important for us finishing up the submission. And it's gonna be even more important as we move into actually making this an adopted standard. How many
people are in this sort of group that you're talking about? And he I mean, it's not just you two,
no, no. So we have a group that's called a system LV two submission team. And it works in effect outside of the OMG. It develops the proposed specification, and then at submits it to the OMG. So this group system, I'll be to submission team has something on the order of about 80 companies represented, and about somewheres, Around 200 people that are, have been participating varying levels, you know, some are very active, and others are, are not. So you have sort of the full spectrum, but it's a, you know, there's a substantial number of folks, maybe I would say 2530 that are quite active on it on a regular basis.
What's the problem you're trying to solve? What is it just take us through that why this is important?
Okay, so just a little bit of background, if you bear with me, through that bear away, maybe, yeah, so bear away, but it's all about, for me, it's all about as a system engineer, this is improving the way we we engineer systems. And, you know, as system engineering is all about, trying to basically ensure that the pieces of the system work together to achieve the objectives of the whole. That's what system engineers do. And they do that by meeting with the customer, understanding their requirements, developing or their needs, developing requirements for the system, architecting, the system flowing those requirements down to the components. So that's what they do. And in years past has been what we call document centric. There's a lot of documentation required for that. Yeah. So for example, system specifications, interface control, documents, analysis, reports, all this kind of architecture, description, documents, things like that. All that capturing all that information about the system in these different documents is a real challenge to keep it in precise, complete, consistent. So the idea is to have a modeling language that captures that same information in the form of a system model. So it's analogous to a electrical schematic, but a very sophisticated one that that's more generalized to describe systems rather than a circuit than an electrical circuit. So you're describing functionally, what it does, how it's composed, how whether its interfaces, key properties, things like that all about the system, and use that information to ultimately to specify from the customer level down to the components. And then designers detailed designers work on the detailed design based on that model.
So it's so this is to you, Ed. Again, it and you definitely there's an exhaustive effort to make sure that you're really capturing everything. Yeah, it is just unanimous. I can't say there's, there's a lot of work and effort. So once it's once it's been approved, once it's been, you know, thoroughly evaluated and said, You got the imprimatur boom, you got the stamp of approval, and it's out there. It goes on the OMG platform. What do I get from it? What where am I at you guys sort of there it is, what do we get?
So we're already in the process, actually, of moving to a post adoption kind of world versus mov two, unlike a lot of work that has gone on and OMG standards where a lot of the actual Old community of users wasn't formed until after the standard was adopted. The system LV two, we already have a first version that very active. Not only that, but we made the decision early on that rather than waiting until adoption, we were going to actually build open source pilot implementation that actually provides some of the capabilities of the language as we developed it. So we could have an agile feedback loop. But by making that publicly available, we have people who are already using Cisco v two under the understanding that it is still not final, but that are already working on it and already applying it and giving us feedback. So what will happen is, when we make this final submission in February, it goes into the finalization processes OMG, where at that point is supposed to go out as a beta standard, and get feedback. But we've already been getting a few years worth of feedback, we already have a commercial vendors, major vendors working on implementations of this. And not only that, but because they have this pilot reference, we really feel we will get consistent implementations, which was an issue, you do a standard in order to allow the users to be able to move between different vendors have other tooling that goes around that to do the kind of systems engineering analysis on the models. It's all based on having a consistent standard. But that was very hard to get done system LV one with V two we feel will go into this post adoption finalization period with already vendors focusing in on having a very standardized language and other tool providers building on top of that, already being able to demonstrate the ability to use their tools. So we feel you will immediately see a benefit in the community of engineers being able to express themselves in a common language. And tool vendors been able to provide support for them to do sophisticated analyses on these real system engineering models. And I think that's gonna, you're gonna see that next year.
So you want to add to that
I do I just, you know, just to clarify, though, that you know, the language, I mean, we deliver a specification of a standardized language for describing systems. So it's like it's, it's kind of think of an electrical schematic analogous to that. But tool vendors, take that language and implement it in their tools. And then I as an end
user, real quick define a tool.
This tool would be like analogous to, well, let's use a CAD tool, like a computer and computer aided design tool that specifies the geometry, for example, which people are very, you know, typically familiar with, this would be a similar kind of tool, but it's but stead of specifying, let's say, the geometry should also does to some limited extent, it focuses on the functionality of the system and the interfaces and performance aspects. So it's characterizing the system, not so much from, you know, here's the geometry of it, but what it does and how it does it and things like that. So as the tool allows me as a system engineer, to go in, and basically develop, specify the system. So you could start sometimes with the green sheet where you have no information you talk to customer get their needs. And now out of that you have to form begin to formulate this concept of a system that meets those needs, you use the tools with that implement the standard language to describe that system, it could be an aerospace and defense system, it could be a transportation system, it could be a manufacturing system, it could be any kind of system that we're talking about here.
And one thing I think worth adding to that is that we're not only providing the language, we're providing a standard application programming interface for being able to access representations of models in the language. So that was a significant additional piece. It's actually a separate RFP, supporting the language because, you know, we talk about it as a language, and you may think of it as a picture. But it's more than that. It's a bunch of information. It's closer to what you get in a computer aided design system, or you have information about the system expressed in the language. And the question is, how do you use that to communicate across a large team, you don't want to go back to it just being documentary, a print out diagrams and whatnot, you want to be able to slaughter the shelves are covered by that, right? Instead, you want to store that in an information system, like they have for hardware for product management systems. And you want to have that information accessible across what could be a multidisciplinary team have all sorts of different kinds of engineers. In order to do that those different engineers are going to use different tooling to access that information, but you wouldn't have access to in a consistent way. And there hasn't been any standard to do that. So that means that different providers of these kinds of repositories of that information have provided different kinds of interfaces, which meant that different other tool programs couldn't interoperate with it, by providing a standard way to access it now, are already seeing different providers of different kinds of secondary tools, analysis and other kinds of software, being able to access where one you could have an engineer create a model put into the repository, and another engineer using a tool by some completely different provider can use the standard interface to get it. It's like providing a standard interfaces that Amazon or Google provides for commercial services, we're doing it for engineering services.
I would imagine the benefit just just throwing it out there. The benefit is that with these systems, with this standard, with these, this sort of roadmap of how to do this, and consistency, there is an improvement of success. Is that the benefit that I receive and saying, Hey, I've got a standard here. I see it, it's been thoroughly vetted and pressure tested, or whatever it might be. And, and that means that excuse me, that gives me the the confidence that that I'm heading down the right way, it doesn't ensure, you know, complete success, it just like OCAP, I've got some standards here. Yeah. Is that what is that what we're talking
about? Yeah, I mean, going back to what I said a few minutes ago, if you contrast our engineering of systems using a model of the system, like like we're talking about here, using a standard language to describe it. And contrast that with okay, we'll capture that same information. But we'll do it in this document. And that document in this document, it's informally specified, it's in text, which is not as precise. And it's in maybe a Visio drawing tool. It's in an Excel spreadsheet in a PowerPoint slide. It's in Joe's desk.
How much is still done in an Excel? Yeah.
And and it has always been on this side of the
PowerPoint and Vizio word? Yeah, that's where I mean, if you look at these new aircraft that come out, a lot of the ways we developed it was that way, that information is in Joe's desk over there, it's in Mary's, you know, she's got it in a notebook. And we're trying to pull it together and get it integrated, complete, consistent. For Solomon, you know, that's the idea.
I mean, model is this is all about communication. It is engineering, as, especially about communication, all engineering really is about modeling is about providing a way to communicate this information consistently. And by having a standard, you know, even if you did it within a project, you do it in English, everybody speaks English. Well, that's already sort of a standard, but it's not precise. So you have to make your vocabulary, you have to have glossary, yes. So if you have to do that on every project, then that's time wasted from actually doing the engineering. So if you can agree on a standards, everybody is already going in using standard terminology, using standard ways to express things, and then has vendor tooling that supports that standard way to do it. Well, you can get to what you want to do, which is not build your modeling environment, which is using it to build your airplane or your medical system or your automobile. Yeah.
And in addition to the communication aspect, which is critical, particularly as Ed said, for System Engineering, it's also automation. Because if you standardize on this, you have the ability for computers do assist you by evaluating the model, for example, and can do checking and see if there are errors, for example, or generate reports and things like that, which you would normally have to do by an effect by hand. I mean, so this makes a big step forward.
That's a lot of lifting. Yeah, that's a lot of lifting and what I can see is that, okay, so you got version two, you roll it out, so they're gonna be people that are going to be paying it, they're gonna pull it down, and they're gonna, and it's just the community itself is gonna say, Hey, you missed this or that. How about if you have just, it's just going to does OMG do the like,
No, we're gonna get it perfect this time.
Yeah, it'll be perfect. So right now, change. Now I know. OMG is process supports ongoing evolution, that that's built into their process. So once you come out with a standard, yeah, and the specification, they have what's called a revision Taskforce. And that is fundamental to their process so people can continue to identify surface issues or new needs and what have you and then you can evolve Have the specification.
Yeah. Because and then then you come to a quarterly meeting and saying, Hey, we've had these, this type of feedback, and can we debate it? And can we include it or, and it just, it's just, I love the, the, the iterative process the collaboration to truly an end. And I love the passion to try to, you try to do it, right. And it's, it's not, it's not just something that, hey, we're the, you know, we're the kings in the neighborhood. And this is what we, you know, tell, you know, it is truly a community that's trying to get it right. And that
community is unique here at Don G. And that it has the end user representation like myself, I come from an end user community worked at Lockheed. And it also has the tool vendors that build the tools that we're talking about, like, oh, yeah, computer aided design type tools. So they're part of it, academia is part of it, people who are learning from people who teach it. So you get a very broad perspective, it's international. So you're getting a broad representation. So it's really quite a, you know, it's a pretty darn good process
and the process, the revision process, and active standard at OMG, will typically come out with a point release every year to two years. And that's what happened with system L over it's gone from system a one to 1.7, over a period of like 10 to 12 years. And that's much different than most other standards organizations. Your typical international standard might be revised every five to 10 years. While at OMG. You're having an update, driven by the community, with attention paid to backwards compatibility happening every year, two years on on an active standard.
I don't see how you cannot do that. Given the velocity, a speed that it's blistering. I can't keep up with it.
Part of the issues with a lot of standards where the process is slower is they can't keep up and then people don't follow them. Because they're not keeping up with a neat
bingo. Point. Yes. Yeah. No, you're hitting on all cylinders. Sandy, how do they get ahold of you?
So you can reach me on my email? "firstname.lastname@example.org" email@example.com as safe firstname.lastname@example.org.
All right, and you Edie,
I work for model driven solutions. You can reach me at at dash s at model driven.com.
This is great. You guys are great. I really like this stuff. Maybe I'm maybe I'm one. I'm one. I love it. You guys are just awesome. Thank you. Thank you for spending time in the schedule and being here and making and doing what you're doing. All right. All right, listeners, we're gonna wrap it up on the other side, we're gonna have all the contact information for Sandy and Ed out on industrial talk.com. So stay tuned, we will be right back.
Thank you. You're listening to the industrial talk Podcast Network.
All right, a hearty thank you to Sandy and Ed sharing their insights into system modeling language. And the standards associated with that a big time. Kudos to those two gents. A lot of it's happening at OMG. A lot is happening with standards that we just take for granted. We just don't know if they just they just exist. You look at the world you don't know how standards are positively impacting the way we do business and our life big time. All right, we're building a platform out at industrial talk. It is a ecosystem and expanding ecosystem of professionals such as Sandy and Ed. You need to be a part of it. You need to participate. Because you just go out to industrial talk and say Scott, I want to participate. That's it. Have a conversation with me. Let's see what we can do. Be bold, be brave, dare greatly hang out with those two jets. You'll change the world. We're going to have another great conversation coming from OMG shortly