MBSE Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.


{{:mbse:smswg:2016-01-21_challenges_of_collaboration_through_shared_models_1.jpg?600}}

I appreciate the chance to raise some basic challenges and pain points as we rely on computer-based models to communicate and collaborate in future product development.

I come at this from the perspective of many different industry, research, and internal project groups I've had the chance to be part of over my career at Deere. Please be clear, though, that I’m presenting a personal perspective, and not speaking specifically on behalf of John Deere.

{{:mbse:smswg:2016-01-21_challenges_of_collaboration_through_shared_models_2.jpg?600}}

I’m not going to use a lot of slides but this is an outline of the entire talk. I also have presentation from ten years ago that's downloadable and still serves to summarize a good bit of unfinished business.

Here are some of the groups I was involved in then. There were lots more before them with a bias towards data modeling, computer science, and formal AI. My original background was mechanical engineering but I got sidetracked into modeling issues over 30 years ago.

I got back into engineering around 15 years ago, and I’m excited about this real live testbed to explore how collaborate in new ways, by sharing of model-based content in technically precise domains.

The first part of this talk is more heavily technical. That’s partly because of who I am, and also because of a fundamental point I’d like to make, which is that we need basic progress in modeling foundations for models to play all the roles we’ll need them to fill.

We need to recognize that models are a new form of language by which we’ll communicate in future product development. The models we need aren’t just analysis and simulation of well-defined physical systems, but many kinds of models including basic information to coordinate our efforts in a larger system context. That’s the core of cross-disciplinary systems engineering, which is still an emerging practice in many commercial organizations [Ref Slides 5 & 6].

This is the field I’ve been involved in more-or-less continuously since the development between INCOSE and OMG of the Systems Modeling Language, or SysML. SysML can cover part of the systems engineering context, but there are many ways to slice this content and express it through multiple notations and management forms. There’s still no decent solution to cover all of this.

That’s a real disappointment. This isn’t really complicated data. A lot of it is just documentation and metadata, but we need to publish it everywhere with ready access so everybody can work  on the same page with agreed-upon boundaries and goals. That’s true throughout the hierarchically nested structures of systems made of subsystems all the way down to bottom-level components. We need a system model that keeps track of what connects to what, and which piece is responsible for which contribution within each system boundary.

We may want to express this information in all kinds of different diagrams, but many of those are just variants of schematic block diagrams, with boxes and lines and connection points just like a Visio diagram. How many different kinds of schematic diagram editors do we really need? Why can’t we use generic tools for system architectures with customizable legends and a real database behind the scenes?

Backing up to requirements management, it’s disappointing how much may be involved even to capture a simple tree of requirement statements, and then to drive them through a change process to downstream activities, where we need to remember and keep track what each element is responsible for accomplishing.

It’s troubling that a separate class of tool like requirements management is even necessary. These are data structures of minimal to moderate complexity, which general-purpose data management systems should be perfectly capable of managing, with a bonus of dictionary-controlled content and lots of other standard services.

One of the main points I’d like to make is that we need to democratize the sharing of product development collaboration data. That's all that model-based systems engineering really is. It’s not the deeper analysis, simulation, and design models that actually know something about their respective domains. Systems engineering provides a glue that can tie all the other models together into an overall systems context.

We can’t scatter the systems engineering data across multiple tools that slice and fragment their coverage in all kinds of disjointed ways. We shouldn’t allow the fact we’re working in engineering to obscure the structure of the needed data elements, which are simple enough in their own right. We need to ensure that everyone in an organization is driven by a shared blackboard of a common system architecture.

I could stop here and be happy with I've covered, but let's go on to some additional wishes to expand the range of models that add value to the definition of whole-product systems.

One of these is agent-based modeling [Ref Slides 35-38]. At last year's ASSESS kickoff, this was one of the topics I raised, to model the customer usage context in which our products are applied. We need to look at the population of actors who interact with our products, a continually shifting assortment of players who come and go.

I was one of the core developers of an early open-source toolkit for agent-based modeling called Swarm [Ref Slides 40-43]. It was one of the catalysts for agent-based models to become a core research method for complex adaptive systems, ranging from social systems to economics to biology.

I’m interested in restarting development of a Swarm-like simulation toolkit using some of the abstract layers I’ll talk about shortly. I think the dynamic populations and interactions of agent-based systems are essential to capture the real-world usage of our increasingly connected products.

[Ref Slides 47-48]. I was also a core architect of the parameteric modeling capabilities of SysML, which I think have untapped potential to capture both logical and algebraic constraints on the elements of a system. One of the encouraging trends in software development today is the emergence of functional programming from an academic hiding place to a visible and growing programming practice, in languages like Scala, Erlang, and Clojure.

Logically, I think that functional programming can be expressed a special case of logical constraint programming. We’ll eventually need not only mathematical equation solvers for our engineering models, but constraint satisfaction solvers, like TK Solver once tried for basic spreadsheets.

Here’s one example of how libraries of internal model constraints could express a textbook problem of functional program [Ref Slides 49-51].

I’ll skip over what I think is clear need to integrate all our different kinds of models with each other. We’ll know we’re successful when we can build a full functional simulation of a product including its application usage context, and use this structure to tune in and tune out all the more specialized models to answer questions we may be interested in.

I mentioned at the outset that we need progress on basic modeling foundations. The so-called Semantic Web offers some candidate layers of this foundation, but still suffer from too much complication including an over-emphasis on literal encodings. I think we need a more conceptual form of semantic data modeling that  supports translation into multiple encodings, all the way into visual diagrams for users.

The same mechanisms that allow model translation can also support automated synthesis of design solutions. One of the other topics I raised at last year’s ASSESS kickoff is to bring back the field of knowledge-based engineering, in which we automate design rules but in less geometry-fixated forms.

Let me wrap up with some of the less technical challenges, which may actually loom as the higher barriers. I’ve been involved in many different industry standards groups, going back to the early days of STEP and switching in and out of many groups as my patience wore out or got refreshed.

Even with all this frustration, we need our technical solutions to get accepted and institutionalized from multiple sources. One of the economic issues is how extremely inefficient the progress by formal standards groups turns out to be.

From all my time these various groups, I can’t claim to generate a timely return-on-investment that a company like Deere would normally expect. At best we can claim our participation kept us better informed and able to steer our internal programs.

A final path I hold out lots of hope for are open-source approaches to basic standards and their reference implementations. It’s important to recognize that open-source development powers nearly all the web and internet including most online services. We need to be prepared for similar layers in engineering.

One kind of collaboration I think we should consider is to develop reference examples of fully worked product models in some domain that's not a threat or exclusive claim to any specific company. Let's explore all the ways we could make models relevant and useful to a wider audience.
MBSE Wiki

User Tools

Site Tools

Page Tools
