By Ron Kratzke, Principal Systems Engineer
When teaching classes on model-based systems engineering, I am frequently asked about methods to manage different system configurations in the model. Most engineers are very comfortable thinking in part structures, and while this is a critical aspect of systems engineering, it’s not the whole story. To answer the question and manage variants, we leverage the generalization/kind of relation in parallel with part structures.
Classical systems engineering is concerned with the decomposition of our physical architecture (the bill of materials). In the Component class, this decomposition structure is captured using the parent-child relation built from. A system is built from its subsystems, and those subsystems are built from their constituent parts. An automobile is built from its chassis, drive train, engine, and more. In the Geospatial Library example provided with CORE and GENESYS, the Geospatial Library (the system of interest) is built from the Workstation and Command Center subsystems.
Graphically, the decomposition of the physical architecture is shown in a classic physical hierarchy or a SysML structure block definition diagram (BDD). Both diagrams represent the built from parent-child relation.
One of the most common and easily made mistakes in the engineering world is that of jumping to solution. It is quite easy to frame any given problem in terms of a solution or class of solutions. But the cost of this mistake is errantly removing from consideration all possible solutions outside that space.
Take, for example, the problem of head injuries in contact sports. Dramatized in the movie Concussion, our understanding of the problem has extended from the acute consequences of a single injury to the recognition that, over time, repeated injuries can result in long-term neurological deficits. Called Chronic Traumatic Encephalopathy (CTE), the progressive degenerative brain disease results from a succession of blows to the head.
The recognition of CTE in aging athletes has triggered an increased public interest in CTE which has been accompanied by a corresponding increase in research around protecting the brain from such repeated trauma. But in the quest to solve this problem, the public and many researchers have fallen victim to the mistake of jumping to solution. More...
By David Long, Vitech President
For over ten years, the systems engineering community has been focused on the transformation from document-centric to model-based techniques. In terms of the Roger’s innovation adoption lifecycle, we are beyond the early adopters, in the early majority, and moving towards the tipping point where model-based systems engineering becomes the expected framework and approach. In terms of the Gartner hype cycle, some are at the peak of inflated expectations, some in the trough of disillusionment, and a few on the slope of enlightenment.
In the past I have shared classic errors organizations make in deploying MBSE and how to apply systems engineering to the deployment of MBSE to avoid these errors. However, there are still far too many sitting on the sidelines, not having started their journey towards MBSE. Time and time again, the same imaginary roadblocks – great reasons not to adopt model-based systems engineering – come up. Some are roadblocks that the community spawned through inaccurate or unclear messaging. Some reflect natural misconceptions that emerge during periods of change. More...