Mission engineering, digital engineering, and MBSE

I attended Bob Scheurer's INCOSE Midwest Gateway Chapter talk earlier this week: Mission Engineering, Digital Engineering, MBSE, and the Like: The One Underlying Essential Attribute. The presentation slides are available here.

Here are a few notes, along with links to the sources, of notes I took during the presentation...


Now, MBSE I understand. Not that I am an expert practitioner, but I understand what model based systems engineering is getting at. I've got one shoulder to the wall separating the usual set of text-based system requirements, trying to push it over into model-based requirements. Let the analyses and the tests do the talking, not just the words.

But: digital engineering and mission engineering were new to me. Sort of—rather their current names were new to me, which was part of the thrust of the presentation. Mission engineering is basically systems engineering at a really high level. It seems to be about designing missions, which would then be the driver for designing or acquiring systems to accomplish the mission. In other words, to repeat, it's just systems engineering. However, put another way: it's systems engineering using currently popular terminology, so maybe there's an angle to exploit there.

Digital engineering seems to be: how are you going to design your individual systems so that they can provide data to a central entity that integrates that data into some other purpose. What that strikes me as, although I am exceedingly ignorant about the details, is the interconnection of things on the web. Each of the individual servers attached to the web send and respond to HTTP requests. Many sites have defined application program interfaces (APIs) that set rules for how external entities can request and use their data via HTTP requests. Maybe big physical systems are coming around to that.

Anyway, the lingering thought is that it's difficult to tell the difference between mission engineering and digital twin and digital engineering and many other buzzwords that crop up from time to time. Maybe they're useful, maybe not—time will tell. In the meantime, systems engineer have to treat them like real things if we want to keep our heads above water.

Leave a Reply

Your email address will not be published. Required fields are marked *