What is Model Based (Systems) Engineering?

In the systems engineering world, Model Based Engineering (MBE) and Model Based Systems Engineering (MBSE), are often used interchangeably, which is incorrect. MBE is the overarching term which is about applying modelling to various specific engineering issues, such as design, using models in the form of simulations, 3D CAD, etc. MBSE is used for higher level system modelling from needs to how the system satisfies those needs, often modelled using Systems Modeling Language (SysML) and to harmonise MBE activities. As INCOSE puts it “Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases”. MBSE brings together three concepts: model, systems thinking, and systems engineering: [definitions based on Wikipedia and MBSE blog]

• Model – an informative representation (e.g. graphical, mathematical, physical) of an object, person or system that abstracts reality to eliminate some complexity. And as as George E. P. Box put it “All models are wrong, but some are useful”.
• Systems thinking – a way of making sense of the complexity of the world by looking at it in terms of wholes and relationships rather than by splitting it down into its parts. Aspects to consider: Chaordic, Holism, Interconnectedness, Emergence & Adaptivity, Discontinuous Growth. See more in #Systems_Thinking
• Systems engineering – an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles. It brings together a number of techniques to make sure that all requirements are satisfied by the designed system. It concentrates on architecture, implementation, integration, analysis, and management of a system during its lifecycle. It also considers software, hardware, personnel, processes, and procedural aspects of the system.

Remark In the rest of the article we use the overarching Model Based Engineering.

The biggest challenges for agile hardware are the physical aspects. Building prototypes and executing physical tests is costly and resource and time consuming making us slower and less responsive. One of the options to deal with this is to replace hardware by software, for example, replacing a physical button by a touch screen button. When that is not an option, we should make maximum use of the fact that hardware is actually digital information until it gets materialized. Just think about CAD models, manuals, specs, product data. With digitalization came opportunities for supporting tools like power calculation, finite element analysis. This still requires a lot of manual intervention, building, integration and testing. It also drives us to rely on requirements and specifications (plan driven approach). The next step is using a model centric approach where the whole system (mechanical, EM, software, etc.) is put in an abstract model. It combines architecture, design rules and constrains, product and control data, simulation models, design tools and algorithms, etc.

The more realistic the model, the more you can do with it. There is a limit to what is economically reasonable to invest (in relation to the expected benefits like risk reduction, cost of delay, agility, automated document/code generation, etc.). The model will never be a full replacement of the real world and, depending on the residual risks, some testing and validation will have to take place afterwards (even if that sometimes means during final launch or going operational).

Benefits

The benefits are huge:

• Collaboration – Model combines different disciplines/departments, knowledge and tooling, and enables a common language, graphical presentation and instant feedback.
  

• Exploration – New ideas, system level simulation, quickly test feasibility, play with options/what-if, architectural and design changes, virtual prototyping.
• Knowledge management – Single source storage and sharing of design decisions, requirements, intellectual property, etc.
• Integration and testing – Automated build and run tests, hardware itself via tools or simulations, as digital twin / stub for software testing, automation of error-prone and time consuming tasks
• Artifacts generation – Automated generation of software, production drawings, manuals, reports.

All of this speeds up the process, increases responsiveness and quality, and reduces risks.

Risks

• All or nothing approach – Building, using and maintaining models does not come for free. It requires significant (often upfront) investment of budget and resources. An approach where all of the system is modeled out in great detail, will slow development enormously, consume huge amounts of budget and resources, and will demotivate engineers and management. First we should determine how much detail / accurateness is really needed for a system or part of a system based on value (risk reduction, feedback, convincing investors, etc.) and required effort (budget, hours, duration, expert required, etc.).
• Blind trust – A model is a simplified version of a system and its environment. The more detail you put into it, the more realistic it can get, but it will never be perfect. It is vital to validate a model by testing as much of it as possible (especially the risky bits). Especially with a very good and well validated model, the risk is that we blindly trust the outcome, base large decisions upon them, and defer real testing more and more. Until we find, too late, that a small seemingly low risk part of the model can have major implications (butterfly effect).
• Loss of competence / craftsmanship – When we start putting knowledge in models and automate the use of it, we start forgetting. It’s like trying to do mental calculations after using a calculator all your life. When things don’t fit the box anymore we have to be able to fall back on craftsmanship. Also, without this basic knowledge it might be more difficult to understand the more challenging design.
• Expertise required – Model based engineering still requires engineering expertise. Implementing a model is a unique task which requires a significant amount of practice and experience. It is not a simple plug and play tool to provide all the answers. Also, often it requires software development. Fortunately more tools come with simple to use (assembling building blocks like Lego mindstorm.
• Dirty output – Automatically generated output like code, production drawings, manuals, often contain little flaws that normally are cleaned up when done by humans. Especially with code, the produced code may run slower (less lean) and harder to read/understand by humans. The output may also need to be made fit for a specific machine to run on and the tooling might need customization or manual intervention to provide that.
• Dirty input – Reusing models is often a copy-paste action. However, if no time is invested in refactoring the copied model so it fits its purpose, a lot of rubbish is left in there which can cause slower or unexpected behavior and bugs.
• Platform dependence – Required tooling and the libraries that come with them, are often closed source. When you want to add or change small things that is not an option. When you discover a bug, you have to go via the supplier which is time consuming and depends on the willingness and priority setting of the supplier. If you want to move to a different platform, all kinds of non-compatibility issues pop up.

Design automation

More and more tasks are taken over or aided by tools. With ever increasing computer power and memory, cloud storage and computing, smart algorithms, artificial intelligence, and others, it becomes better, easier, faster and cheaper to use these tools. This enables us to do things faster, more often, and with less effort so we can do them more often and earlier. First of all we want to get rid of time consuming boring repetitive tasks. Examples are modifying dimensions or configurations, generating drawings, updating manufacturing information, checking for errors and compliance, etc. But also very helpful are tools that aid more complex tasks like strength calculation, air flow, fatigue, heat dispersion, sheet metal bending, electrical power calculations, etc.
When these tools are combined with decision making tools (from simple algorithms to artificial intelligence), we are growing towards what is sometimes called a virtual assistant or robo-assistant, a valid and appreciated member of the team.

According to Herbert Simon (the founding father of artificial intelligence), decision making is based on mainly three things: Intelligence, Design, Choice. We need intelligence to make sense of a (complex) situation by looking around, reading documents, talking to people, etc. Based on that, we can dig deeper/analyse and design alternatives. Now we have the basis to choose. To validate the outcome of our decision, we need to implement and test it. This provides new input (feedback) to close the circle.   

For each of these areas we can look for tools to support us. We can of course start with the simple tasks (like calculating power consumption, detect parts collision), we can then move up to complicated tasks (like fault finding tools, present alternative pre-fixed design options), finally we move up to the complex tasks that require smart algorithms or more likely artificial intelligence (like presenting creative new design options, determine safety hazards and propose improvements). Also, the way these tools help us is dramatically improving. Where in the early days one was presented a list with data and needed a lot of time, expertise and perseverance to make sense of it, nowadays more and more is presented in graphical ways combining multiple sources of data and filtering out noise.

Xtended Reality

Simulation tooling

An accurate (or accurate enough for its purpose) simulation model can reduce the need for building, testing / destroying real physical systems. This can start as simple as an Excel sheet with data and calculations resulting in a pie graph. Or as sophisticated as a virtual car crash simulation using tens or hundred of processors to generate. Besides calculating, by showing how it will look, the possibility to play with it and walk around it, helps to make decisions and collaborate. Some examples you find below in the short videos. There’s the Toyota virtual crash simulator, Volvo chassis simulator, Autodesk / Microsoft demo for an augmented reality motor bike, SpaceX mars landing simulation, Die casting simulation by ProCast.

https://www.youtube.com/watch?v=WHebBPGpXwc

Living Documentation

How to create documentation in an agile way? And, should we even create documentation when working in a model based enterprise? The Agile Manifesto says “Working Product Over Comprehensive Documentation”. Mind the word ‘over”, meaning we valid both left and right finding the proper balance. Documentation may start to sound a bit old-fashioned, but is not to be mistaken by ‘documents’ and still relevant by its very definition ‘material that provides official information or evidence or that serves as a record’. It is basically is an extension describing anything not directly clear to any stakeholder.

In a model-based enterprise, the basic idea is that models take the place of loose documents, meaning we will get much smaller chunks of documentation as part of the model. Some of the documentation will become unnecessary as to how the model is constructed, visualized and how we interact with it. Further reduction can be achieved for instance by adding information directly to the CAD model (model based definition). Of course the best way to reduce the need for documentation is to make a design that doesn’t require much explanation. As goes for both design and documentation, quality takes time. Like Woodrow Wilson once said, “… If I am to speak ten minutes, I need a week for preparation; …; if an hour, I am ready now.”

When we develop a product in increments, we only need to create or update documentation affected by the increment to the maturity level required. It’s vital to be able to quickly find all the documents to create or update, and then to quickly modify them. This requires simple to use high quality model structure, easy to use product data management and content management.

Image copied from Bridging Points Media

For more information, please take a look at the following website: Core Practices for Agile/Lean Documentation. Or, read this book: Agile Documentation.