• LinkedIn
  • Subcribe to Our RSS Feed

Welcome to Community.Vitechcorp.Com

by Administrator

Welcome to the next exciting stage in the evolution of Vitech's online presence. We are pleased to announce the launch of the Vitech Community Site.

Within, you will find many new features we hope you will enjoy exploring.

Features include...

  • Blog topics with comment capabilities
  • Social Media integration
  • Access to Vitech MySupport and the Vitech Website
  • User Forums dedicated to all areas MBSE
  • Forums specific to Technical Support and the University Program

Feel free to browse the current articles and comment, register for the forums and post, and subscribe to any of the RSS feeds on the site. Users that have already completed MySupport registrations can log in to the forums with their user name and password.

Tags: , ,

Categories: Vitech


Language and Model-Based Systems Engineering

by jmaley

Before addressing "language" and its usage in model-based systems engineering, we need to briefly examine the term “model” as well. The term model is primarily a thought construct to determine what is necessary and sufficient to describe and specify a system, although not limited to system description and system specifications. The “model” ought to encompass the system’s life cycle too. The “model” is the means we use to “think” about the problem at hand. Model, in this sense, is much broader than the more conventional usage. Conventional usage nearly always sees a model as a graphical view or possibly many graphics, all related, or some scaled down physical representation of the system. These graphical representations or scaled representations comprise part of the model in model-based systems engineering, but the representations alone are insufficient to serve as a system model.

If a model then, encourages and facilitates us to think, then what do we think about? How do we think about the system? When should we think about certain questions? How do we gain insight so that we can develop successful systems? Is knowledge of a system’s parts sufficient to design a system? All of these questions are expressed using language concepts.

Russell Ackoff’s examination of the difficulties encountered in developing systems and managing system development is laid at faulty thinking and proposes what he calls “synthetic” thinking. Ackoff states that “[s]ynthetic thinking is a way of thinking about and designing a system that derives the properties and behavior of its parts from the functions required of the whole. The whole has properties that none of its parts have. Analysis of a system reveals how it works but synthetic thinking is required to explain why it works the way it does. Systems thinking integrates the two.”[1] The difficulty with analysis alone is that it breaks down a system into leaf-level components. Each component expresses a behavior and the analysis seeks to explain the behavior. Once the leaf-level component behaviors are explained the attempt is made to explain the behavior of the whole from the leaf-level components. Russell Ackoff notes that this approach by itself cannot succeed because a system broken apart loses all its essential characteristics; similarly for the parts. Leaving those using analysis only as knowing how a system works but never why it works the way it does. This distinction between how a system works and why it works is important and effects how one performs systems engineering. This is the heart of model-based systems engineering as advocated by Vitech Corporation and its Chief Methodologist, Jim Long.

Our manner of thinking then affects our success or failure at understanding and building systems. This leads into understanding how the mind comprehends objects and the importance of language.


[1] Russell Ackoff Interview, Strategy & Leadership, Vol. 31, No. 3, 2003, p 21

Tags: , ,

Categories: MBSE | Primer | Vitech


What Exactly is a "Model?"

by zscott

People use the word model in many different ways. They might mean a fashion model or a model plane or a financial model. The kinds of models we focus on are those that "represent" some aspects of a physical reality. It might be the images that make up a model of the human body, or a plastic figure that contains representations of the major systems. It might be a scaled rendition of a plane or a ship or even a set of plans for a landscape design.

One way to describe the concept of model would be to see the model as a "hypothetical description of a complex entity or process." The plastic plane is a tangible description of the real thing. Models can be "literal" like a toy car that mimics the "real" automobile or they can lie anywhere along a spectrum from the literal representation to models that exist as a set of equations or simulations like a complex financial model.

For the purposes of systems engineering the system models that we consider lie at the symbolic end of the spectrum. In this sense we mean specifically models of systems or "systematic representations of systems." From an engineering perspective the model must span at least four domains (requirements, behavior, physical architecture, and verification & validation). It must also consider and describe the entire lifespan of the system from problem identification to the initial concept to retirement.

It is important to note that graphical representations standing alone are NOT the complete model. They express aspects of the model but, in our context they are not complete enough to be seen as models themselves. They are representations that derive from the model. Taken together they can give us a detailed picture of the model but they are not the model itself.

One of the critical aspects of a systems engineering model is that of relationships. In a global sense the system relates to the external world in a variety of ways that must be captured in the model. Internally the system components relate to each other. This is very similar to the global relationships of the model to the world around it. This becomes apparent when we think of a component as a "system" and the other components as "externals."

This is why the graphical representations are not sufficient to depict the system but must be webbed together with a "language" that expresses these concepts. The language sets up relationships between the system and its externals and between the internal system components. This makes the model robust and ultimately, executable. Without the relationships the most we can have are symbolic representations of the model.

Tags: , , , , ,

Categories: MBSE | Vitech

how to catch a cheater