What are the most effective ways to create accurate models?

In my experience, this is a common pitfall: disregard the importance of clearly defining the purpose and scope of the model. There is a kind of anxiety to talk about technology and rush to define a "solution". To have more chances of success, and avoid unnecessary complexity, we should start with a central question that clearly defines the problem to be solved, work in collaboration with stakeholders, and explore the boundaries of the system in high level of abstraction. Then, purpose and scope will become clear.

Ask this simple question. Do I have a solution in search of a problem? Or a problem in search of a solution? If the first. Stop. That's the role of Business Development, not engineering. Use models to tell the story of how there is a problem your solution can solve, but don't fool yourself and your customers with the allusion of shiny models as a replacement for critical thinking.

In my experience before you start to consider any of the details or solutions to the model you need to fully define a clear set of user requirements and document this in a user requirements specification that can later be cross-referenced to prove the suitability of the end solution. If you follow the V&V lifecycle as a method then it gives excellent clear steps for this type of work

In my experience, models should take the horses for courses approach. Having a very complicated model for representing high level features or dynamics of the system will not help. Similarly, having a low fidelity or crude model to represent a finer aspects of system dynamics will not also help. So, determining the right level of the models is critical to start with. Also, if there are parameters in the model, it should be ensured that those parameters values are clearly available. FInally, computational efficiency of models should also be kept in mind.

The best quote I always think of is, from George Box, "All models are wrong, some are useful." So models that are 'good enough' are the way to go. After clearly defining the question your model is intended to solve, ask yourself several questions like: Will it have an impact or will it make a difference to the stakeholders? Has someone already made a model you can adopt versus creating your own? How much time and effort is this going to take and do you have the right skills to do it? It's important to be candid and realistic about those answers. However, in answering them, if things are becoming overly complex, step back from the problem, check your assumptions about the problem you're trying to solve, and see how you can simplify it.

People get hung up on molding approaches. Again, what is 'good enough' to get going. Often the limitation is in skillset and you just need to use the skills you have to answer the question. 'Agile' methodology has it's issues, but the first tenet is solid: people and collaboration over process and tools. If you find that the approach is not aiding collaboration and communication, then stop using it and find one that does. If you don't have the right skills on the team, then that is the problem you need to address. Most methodologies will work, the key is focusing on the goal of facilitating good teamwork and communication so everyone understands what the problem you're trying to solve and what needs to be done.

In project and program management at our company we're sometimes called on to provide what's known as a Detailed Action Plan. It's really a schedule model using a network diagram of key events leading up to a major milestone. The problem has been that the modeling template is PowerPoint based, which means the PM is keeping two schedules; one in MS Project and one in PowerPoint. So I've created a customized MS Project template using a flag column to identify the items to show up in the network diagram. Filter for that column, then apply a Network diagram that has been customized and we have a single source of data for our working schedule and schedule model. The graphics aren't perfect, but it's a leaner method.

No matter what language is selected, the modeling approach should attempt to capture a complete, correct, and consistent representation. I believe strongly that the modeling approach must be subordinated to automatic validation; if there are two ways to capture information, and one ways can be automatically tested and one cannot, choose the approach that supports automation.

Choosing the right modeling approach involves deciding between supervised or unsupervised learning, regression or classification, and potentially using ensemble methods or deep learning for complex patterns. For language selection, Python offers rich libraries and readability, R is known for statistics, Julia for speed, and SQL for database-driven models. Consider community support, scalability, and team expertise when choosing to ensure the selected approach and language align with the problem, available data, and computational resources for accurate model creation.

I basically agree, but you also need to be able to adapt your model to reality. As the reality will change many times, you will need to change your model as well. This means that your modeling process and tools have to be flexible and easy to use.

For integrated circuit models, I develop the model based on behavior defined in the IC datasheet, making sure to use the same names for parameters that are defined in the datasheet. This makes the model easier to debug and make the model easier to understand for others. The model should include behavior from the datasheet table and secondary effects such as temperature can be extracted from nominal graphs in the datasheet. Test circuits should be created to test the behavior against the datasheet values. I also make it a point to embed stress ratings in the model, so that stress analysis is always calculated when the model is run. Stress limit names also match the datasheet for simplicity and transparency.

The key to good modelling is not only selecting the right language. Also the right framework. The challenge is then to apply it in the whole organisation and motivate the people to use it.

Whatever approach is selected, tailor it to suit your needs. My team and I find that the best way to illustrate the modeling style is to make a model-based style guide (not a document), backed up by short, task-based videos. Enforce it with automated validation (improves quality and supports training). Review the standards...but ensure your approach minimizes friction with your modeling tool and language. You aren't being graded on standard compliance...you should be graded on impact, quality, and cost effectiveness.

Creating accurate models involves a systematic approach: Define the problem, gather and preprocess data, perform exploratory analysis, engineer and select features. Choose appropriate models, train, validate, and fine-tune them while evaluating performance. Validate using cross-validation, document processes for reproducibility, adhere to ethical standards, and deploy models while continuously monitoring and updating them. This method ensures accuracy, transparency, and ethical considerations throughout the modeling lifecycle.

What I have to say is limited to the functional modeling of systems. Said another way, building a model (or models) to illustrate what a system is supposed to do. Sadly, I don't think there is much good guidance for those types of models. The best approach right now might be to think long and hard about the point of any model, who will use it, and for what reason. Do that exercise in the beginning and then revisit it often.

By being creative. When we feel trapped or stuck, our minds naturally go to "worst case scenario" mode and start imagining all the possible negative outcomes. This causes a lot of anxiety and stress, which can actually lead to us becoming even more trapped or stuck. The key is to break out of this cycle by doing something creative instead. Draw a picture, write a poem, make a list of things you're grateful for, or just take a few minutes to do some deep breathing exercises. Anything that gets your mind thinking in a more positive and expansive way will help you find a way out of the situation. Trust that you will find an answer if you keep looking for it!

Collect accurate facts over significant time and analyze all changes. The data must be related to activities or the detail of conditions along with changing reactions. Also, a baseline should be reached in order to identify the pool of normal conditions and reactions. And the data must be presented in a logical order with notations at key data points. This is where consistency in terms and language used is very important. All outliers must be identified and explained in order to realize the true outcome of what is called an average change in condition. There are many visual tools that are very useful to explain conditions and changes across a time continuum. References should be notated in an orderly fashion and clearly relatable.

Ensuring that you include engaging with subject-matter experts and integrating your models into your organization's digital toolchain is a must for success. Use the right tool for the job...don't twist a SysML model into a pretzel to run a simulation that could be done in 5 minutes in Python or MATLAB. By the same token, use the SysML model and its simulation capabilities when it is the appropriate tool for the job.

A very important step in the creation of accurate models is to choose the right level of detail. Often the connection of a coarse model with a finer model gives a better approach to fast and reliable results.

A good research is necessary in order to realize which tools and techniques are in order. Don't be afraid to ask for help and good ideas.

Automated validation within a SysML tool can check for completeness, correctness, and conformance to modeling style. You will need to engage with SMEs and craft appropriate validation methods for other aspects of the model (and the associated simulations/executable portions).

Only VV&A your model when it can accurately predict past events. For example, weather models should be able to accurately predict recorded weather patterns and events before it passes VV&A.

If you don't know what a validation and verification matrix is, then go learn about it. When you are defining the model requirements, you should have a valid test or metric that defines success for meeting that requirement. Sometimes you have to decompose your requirements into many and decide what are the most important aspects that contribute to the success of meeting the requirement. You don't have to build this matrix all at once, but starting with the most important things that you know as there are always unknowns and you'll refine this along the way. This also is a good communication tool so everyone agrees on what the system is trying to achieve and what are valid tests that can be done to verify its working.

Document your process, decisions, and results. Maintaining a comprehensive record ensures transparency, facilitates collaboration, and provides a valuable resource for future projects or model updates. Regularly update the documentation to reflect any changes or insights gained over time.

If the model doesn’t agree with the real world data, correct the model. Don’t cherry pick the data like is being done with the climate models!

In 1976, a British statistician named George Box wrote the famous line, “All models are wrong, some are useful.” His point was that we should focus more on whether something can be applied to everyday life in a useful manner rather than debating endlessly if an answer is correct in all cases. This is true for architecture models as well. Their usefulness depends on the problem you try to solve. Models are abstractions. Like maps, or miniature architectural models, or schematics, they cannot capture every detail of the object or system they are based on, if only because they do not exist in the real world and do not function in the same way.

Just start. Too many people get hung up on how to make a perfect model that they never get to making a model. A bad model can be fixed, but nothing can be done with no model.

It’s helpful to know where you fit in the big picture - Systems Engineering was born from the need to manage complexity. Model-Based SE holds to that same purpose. Without SE staying core to what you do as an MBSE-er, you’re reduced to a draftsman. Similarly, if you try to steer MBSE out of its proper lane, you become a hurdle to the rest of the team rather than a boost.

It is very critical that the model includes all relevant significant inputs, eg constraints, forces and environmental factors. Much wisdom and experience required to get the critical and eliminate the insignificant

First define scopes of work and Ways of modelling depending on system approach, Then specify the requirements and techniques for simulating and programming language best for operation.