Modeling is one of the core techniques in Systems Engineering to facilitate amongst others communication, discussion, exploration, and validation of system specification and design. Modeling can be applied at all levels, from detailed design simulations to high level context models. In practice we struggle with finding the appropriate models and the appropriate level of abstractions. Quite often designers keep on extending and detailing their models. But is the additional effort worthwhile? Is the extended, more complex model better than the previous simpler model? Can we trust the outcome of our models? Should we integrate all aspects in one integrated model?
Let's look at some real life scenarios:
Scenario: The complex not trusted model. The pre-development team has made an extensive model of the system with tens of parameters and possible design options. Unfortunately, designers don't really trust the model, because of its complexity. Since they don't understand what the model does, they don't trust the results. What to do to escape from this cul-de-sac?
Scenario: Assessing system performance from subsystem models. For three different subsystems models have been made to explore performance for a few different design choices. The system designers face the challenge to combine the results into an integral system performance assessment. By making a fourth system level model they trigger the communication between the subsystems and facilitate system-wide design discussions.
Scenario: Overoptimistic performance prediction. During system integration the design team observes behavior and performance that is completely different than expected from previous system and subsystem models. They discover that several housekeeping tasks of the system have not been modeled and have been underestimated significantly.
Scenario: Introduction of Model Based or Model Driven engineering. The development organization has scheduled a transition to model based engineering. The expectations from management are high. Engineering teams are sent to education. Unfortunately, after 2 years of development the team discovers that there are plenty of detailed models, but that system characteristics “emerge”, because system level models have not been made.
(sub)System engineers, designers, and architects who create, maintain or use models. This course looks especially at multi-disciplinary models.
Prerequisites: at least bachelor in engineering or science and some practical experience in design and engineering.
The objective of the course is to teach system engineers and architects methods and techniques for achieving an effective transformation from requirements and business drivers to technology and product design.
After this course students will be able to:
understand what is a model, types of models, purpose of models
understand the need for quantification and understand the limits of quantification
be able to transform loose facts into an insightful model, to be used as input for requirements discussions and system design and verification
be able to use scenario analysis as a means to cope with multiple alternative specifications and or designs
apply problem-driven light-weight simulations and understand their value and purpose in early design decisions
understand and be able to apply the threads-of-reasoning method as a means to communicate about, and discuss the linkage between, business needs and technological decisions
be able to analyze dependability qualities, such as reliability, safety and security
be able to analyze the impact of changes; change and variation cases
understand the value of rapid prototyping for: requirements, potential design issues, modeling inputs
be able to manage expectation level of different stakeholders
teach system engineers and system architects how to model and analyze their system under design, and evaluate alternative design options
teach them to understand the complexity of this task
provide them with adequate methods, knowledge, techniques, and methods to be applied in their daily job
The course takes 5 full days. Participants taking
the course for credits have to do a 10 week project afterwards.
During the course participants work on real-life cases, preferably
from their own domain. Theory and exercises alternate continuously.
The models created during the course are limited models, since
creating real simulations would take too much time.
The exercises provide even more value when multiple participants from the same company participate. We recommend to send a small team to the course, if possible.
During the course we address the following questions:
do we model?
What are the indicators that show that modeling and analysis beyond the level of "business as usual" is needed? What questions do trigger modeling and analysis?
do we model?
What kinds of views do we need to consider (4+1, DoDAF, Zachman, CAFCR)? Do we model everything that appears in the relevant views?
do we model?
What models are needed at various points in the project life cycle?
is the appropriate type of model?
Formulas, visualizations, simulations/emulations (replay of (aspects of) the system), executable models (the model is the system).
is the required accuracy of the model?
How do we achieve the desired risk mitigation?
is the appropriate level of abstraction?
Model economics: How much details have to be taken into account versus how much effort can we afford?
to calibrate models?
Models are based on facts and assumptions. The model outcome depends strongly on these input data. Note again the tension between effort to make and calibrate versus the value in terms of risk mitigation.
to use models?
What is the working range, what are restrictions to model validity? What is the credibility of the model?
This course focuses at system level and the multi-disciplinary design. We strongly emphasize the objectives of the modeling effort: Most modeling effort supports the decision process of the project, such as what are feasible requirements and what is the impact of design choices. The modeling effort itself helps the designers to understand their system much better. Since a model is a simplification of reality, we need to calibrate models with the real world by performing measurements.
The course is based on several complementary principles:
continuous iteration and time-boxing
gradual refinement from coarse estimates to well-supported results
visualization of problems and solutions
quantification of problems and solutions
complementary representations such as formulas, graphs, tables and diagrams
The following topics are covered:
Introduction and overall approach
Fundamentals of modeling and analysis techniques
Use case analysis, story telling
Architectural Reasoning, linking business to technology
System Analysis: robustness, sensitivity, dependability
Volume modeling and analysis: performance and resource management when scaling up
The course fee for a course week including all course materials, lunches and coffee breaks can be found at the Systems Engineering page of Buskerud and Vestfold University College.
To register please send an e-mail to: email@example.com with the following information:
Name and mail address for each participant
Name of company
The number of participants is limited.
Courses are taught at Buskerud and Vestfold University College in Kongsberg. Courses can be customized or taught at location, contact us to discuss needs and opportunities.
For more information you can send an email to