Design Guidance
Overview
This page is a collage of best practices of guidance, best practices, and lessons learned. If there was one way to summarize all of the best practices into a few sentences, it would be "use moderation when modelling". Whether that be determining the proper fidelity, levels of abstraction, complexity/simplicity, or number of elements on a diagram, there's a Goldilocks level, optimal level, of every aspect of modelling.
Design On Purpose
We start with the end goal and work backwards, breaking down the problem into smaller parts. This helps us create a plan to reach our goal, and allows us to prioritize the tasks that need to be completed. We also consider the user experience and how to make the product as easy and efficient to use. This helps us create a design that is both functional and aesthetically pleasing.
Remember you are trying to make the model useful; when and doubt focus on making it useful. As George E. P. Box stated, “All models are wrong, but some are useful…the practical question is how wrong do they have to be to not be useful.” A design should: "meet the functional need, is robust and durable under stress, and gives the user pleasure." (pg163, The Design of Design: Essays from a Computer Scientist). In order to achieve this , a designer must strive for elegance: one definition of elegance in mathematics is “accomplishing a great deal with few elements.” (pg142, The Design of Design: Essays from a Computer Scientist)
Page Intent: Rumble Strips
Don't get caught sleeping during your design process as you can easily take a tangent and end up driving the wrong direction. This page is intended to act as the rumble strips alongside the road; when you start to veer off the path, this page's text will give you the red flag and guide you back on the middle of the highway.
A Taste of Some Design Guidance
Modularity, Scalability, & Reuse
Creating a system architecture which is modular and scalable requires brainstorming to determine what data is available to date and what will be available in the future.
It is critical to design a model which can perform tasks in a timely manner which means attention to computational speed will be a consideration.
Academic vs. Practical
While being "right" is nice, that solution may be too tedious to implement for a large project. Oftentimes the academic solution unfortunately is not scalable due to unforeseen issues such as computing power, computing speed, timeout issues, or bugs which arise. This page serves as a guide to show best practices to build and grow full scale models through the design lifecycle.
Cameo Threads
Cameo can "Thread" to other softwares. This allows for content to be passed automatically between tools. Threads, while difficult to implement, are critical to keep model maintenance low, and allow Cameo to act as an up-to-date source of truth.
Rule of Thumb: Design to minimize the number of “tosses” back and forth from Cameo to external softwares to minimize computation time and bugs.
Simulation Fidelity
The team must understand what inputs are available and how precise the input values are. The simulation fidelity should ideally match the level of fidelity of the input values.
Swapability
This includes everything from universal payload swapouts to complex engine or flight computer swaps/upgrades.
It is important to understand classes and create a robust architecture can scale for new future products. The dual function and location methodology has enabled endless scalability.
Additional Guidance
Terminology
Design vs Architecture
"Consulting a number of glossaries does indeed support the opinion that these two terms are synonyms. The term "architecture" is frequently related to high-level design, typically involving multiple disciplines to realize the system elements. The term "design" seems to be used when only a single discipline is involved to realize a system"- (Model Based Systems Architecture, pg21)
System vs System Architecture
"A system is a combination of interacting elements organized to realize properties, behaviors, and capabilities that achieve one or more stated purposed" -Dickerson and Marvis
"System Architecture is the organization of the system components, their relations to each other, and to the environment, and the principles guiding its design and evolution" (Model Based Systems Architecture, pg22)
Model vs. Repository
"A repository is a data storage like a file or database, that is, an implementation of a model.. it is important to track the versions of the repositories to define a valid configuration." (Model Based Systems Architecture, pg28)
Elements & Components vs System Element
"elements" or "components": Elements that constitute a system shall be designed with the term "system element" according to the definition in ISO/IEC 15288:2008.
A "system element" may be a "system" in its own right" (Model Based Systems Architecture, pg24)
