Model Paradigm for Engineering

Model-Based Engineering (MBE) is getting more attention these days and in order to explore it, I came up with this certain sort of a roadmap.

To set the stage for the discussion of the model paradigm, here’s one little problem, the problem of scope and applicability of ideas coming from the community around engineering/design software. The issues we discuss are about data, automation, organization and technology. They are not restricted to engineering and design, they spill out to many other STEM fields, and notably to architecture and art too. The COFES congress, as an example, flies the banners of engineering software even in its name, yet the full scope and applicability of what we call engineering software agenda definitely extends beyond engineering and is more elusive.

Venturing into the model paradigm

I would argue that the most usable notion to differentiate the scope of engineering software world is the notion of model. While it’s a banal fact that computational math permeates all the sectors of STEM, it is modeling and consequent usage of models that permeates engineering and the related fields that we usually connect with it. Model-Based Engineering (MBE) has emerged to get the model into spotlight.

MBE will likely mature and become a typical engineering acronym with an industry of its own software products to service and a host of satellite terms like Model-Based Manufacturing. That means that the term will evolve to deal with a certain and discrete subset of model-related engineering that could be described as “high-end MBE”. My interest here is to explore the usage of models on more simplistic levels that are also hopefully applicable to a wider nomenclature of disciplines like engineering, architecture, geometry modeling, conceptual design, and structural analysis.

A little overhaul to the understanding of model notion

What is good in an emerging technology is that it is often vague and soft enough to slam into. Along the lines of what Evan Yares wrote (see Related Reads), MBE talk can mean different things to different people. This is why it seems reasonable to explicitly redefine some notions to be able to explore the model paradigm freely and in parallel to MBE proper.

The apparently accepted (and the only one detailed enough that I know of) definition of Model-Based Engineering can be found in some relevant NIST documents and it is only rational to start with it. To get your interest, here are some notable differences between this ‘proper’ image of MBE and what we will be setting up here.

NIST take: a model is a representation or idealization of the characteristics of a real-world system

My comment: the essence of model is the representation, aka mapping. Let’s also detail that we want to be able to build models for phenomena that are not usually seen as a real-world system (i.e. a product): design processes, workflows, information flows, down to operations on data storages, files and folders. If there is an activity or an artifact, there is always a model for it.

NIST take: models can be either computational or descriptive.

My comment: instead, let’s accept and develop the free multi-tier classification: models can be descriptive (for existing artifacts) or prescriptive (for those to be designed); declarative (what should we have) or imperative (how to get there); they can be computable, graphical, or semantic.

NIST take: core to MBE is the integration of descriptive models with computational models.

My comment: this is a very ambitious pursuit and this is why I refer to ‘proper’ MBE as something high-end. In the multi-tier classification that we will be using, integration tasks are worth a separate discussion. Instead, let’s speculate that since there always is a model, the goal of model paradigm in engineering is to build the representation for the model that you already have in your head, while also deciding which models are worth building and which should be left in the engineer’s mind.

This is about all for now, so let’s set some goalposts to be headed to.

Where we are going from here

There are subtopics and related issues to model paradigm worth a separate discussion. Here are some of them.

Social and educational aspects of engineering model awareness. If developed properly, model paradigm could significantly disrupt the understanding of engineering with those entering the field.

Terminology, notions, and concepts. We will employ existing knowledge on the subject to describe a conceptual framework of the simplistic model paradigm. Let’s explore a set of goals for model-based engineering and a set of methods and techniques to reach those goals.

Analyzing the toolbox. Where resources to implement MBE are scarce, using existing and low-effort development of new tools matters. Here goes the discussion for butt, UX and user complexity, self-hosted apps and whatnot. We will also discuss how model-based engineering relates to automation and project management.

Data models and the Holy Grail of SSoT. SSoT, achievable or no, is of paramount importance to data model and we are going to redefine it a little, too. Also, ever heard about the death of the filesystem? I doubt it’s that dead after all, at least for the modest effort. We’ll explore possibilities to employ rather low-level, common technologies to empower the engineering of models at the data management level.

Get on board. I actually plan to inevitably screw up a lot in this journey so your input is crucial and will define whether it’s bollocks or not. Over the next month, we’ll explore the model paradigm and the wrap-up will be presented at COFES St. Petersburg this June. Stay tuned at get into discussion at @Twitter and #ModelBased.

Related Reads

• Why You Need to Understand Model-Based Engineering by Evan Yares
• Clarifying the Confusing Terminology of Drawingless Initiatives by Chad Jackson

Previously published at https://medium.com/@abausk/model-paradigm-for-engineering-a6b58bc0132d