UAF or SYSML?

Presenters: Laura Hart, Research Engineer Senior Manager, Lockheed Martin; Gene Shreve, Senior Systems Engineer, Integration Innovation, Inc.

As MBSE practices mature in organizations, the question of "should we use UAF or SySML?" often arises. This question indicates that many engineers don't understand the relationship between these two modeling languages and how they can and should be used together to answer different questions from various stakeholders. This paper will provide a brief overview of each language, its intended purposes and then provide a working example of how the two languages complement each other, aiding the decision process at every stakeholder level.

[luigiturco]

Interesting. I see often choosing UAF over SysML for SoS architecture, and by consequence overlooking the definition of common interface standards

[llvienna]

Yes and yes. Continuum Depends what you are doing.

[ms]

For the segment starting at 12:00 on "Enterprise vs Systems Architecture":

Considering the definition of a "system" from ISO 15288 or the INCOSE Systems Engineering Handbook, one might ask: Isn't an enterprise also a system?

Another perspective to consider:

In reality, the term "system" is a conceptual construct or sometimes just a suffix in a product name used in everyday language. The concept of a system doesn't exist as a tangible entity; rather, it describes certain behaviors and relationships.

Some assemblies of objects exhibit "system-" behavior within the processes they are involved in. In these scenarios, they take on what we can call a "system role."

A "system role" is a role that emerges within a “composition of elements” where, in at least one arrangement of these elements and within the specific process they engage in, the composition exhibits behaviors that the individual elements alone do not.

Therefore, an organization, a collection of engineered artifacts, or parts/elements of nature can take on a "system role" in certain processes. However, in essence, these compositions are simply what they are—assemblies of components with potential behaviors, not "systems" in and of themselves.