Does Model Based Design need software stacks?
In my last job, something I should have known for years became painfully obvious; model development is software development. Maybe this is a product of it being a Silicon Valley company where, ultimately, everything is or revolves around software engineering. But I feel it's a valid comparison. Matlab, aside from valid arguments over its completeness as a programming language, is still at least a scripting language. Even Simulink and Modelica, despite their GUIs and abstractions, are ultimately taking inputs, performing user-defined operations, and producing outputs. And that's not even including models written in more traditional, fully-featured languages like Python, R, C/C++, Fortran, Julia, etc.
Also like software, they need to be verified and validated, have version control, and work within the hardware and time limitations required to deliver their results according to customer requirements. Phrased less technically, they need to work, do what you intended them to do, have their changes tracked, and not take too much time or too powerful of computers to run. Considering how much time and effort has been spent on refining the process by which software is developed, it can't hurt to ask what software engineering can teach model based development (MBD)
This has also been on my mind as I figure out where to focus my time and efforts into learning and maintaining skills, as well as which areas are ripest for that perennial favorite of Silicon Valley phenomena, disruption.
So what is a software stack? This handy Techopedia definition sums it up pretty well.
“A software stack is a group of programs that work in tandem to produce a result or achieve a common goal. Software stack also refers to any set of applications that works in a specific and defined order toward a common goal, or any group of utilities or routine applications that work as a set.”
In most cases I've heard this come up in reference to developers, typically web developers, talking about whether they are backend, front end, or full stack developers. That is, whether their expertise is on the server end away from the level where customers are interacting directly (backend), on the webpage or app level where customers are interacting directly with the service (front end), or across the full range of development (full stack). While you might find similar descriptions in the high performance computing (HPC) world, the discussion of stacks is something that I personally haven't seen in MBD.
An obvious explanation for why this doesn't exist in MBD but does in the web development world is that people build a ton of websites. Billions I doubt would be an unfair estimate. The sheer economies of scale mean that converging on a set number of technologies to use for certain, common tasks saves years of work and makes the whole system more stable and secure (ideally anyway). MBD, on the other hand, is usually the providence of larger, more established companies trying to wring the last 10% out of a product than push something that works out the door before they run out of funding.
But perhaps that's the point. Without a defined set of tools to use that are more or less guaranteed to produce a certain outcome, MBD may be too expensive and too risky to justify in companies that are just starting out. Many companies I've talked to in this position consider this sort of analysis to be something they'll tackle in the future. There are, however, two main problems with this. The first is that people will still be developing models, as most products will need to predict performance of some kind. This may lead to a situation where by the time the company considers itself ready to dive into MBD, it already has mountains of spaghetti code that aren't interoperable, proven, stable, or documented, and may well contain conflicting duplicates or versions. The second is that while MBD is an added cost up front, it has the potential to save enormous amounts of time and money (time/money?) later in the project. Besides making it easier to implement MBD if you do it from the start, MBD makes it much easier to answer questions of product definition, ensure that you're designing a system that best meets all your goals (or a compromise therein), and even test both hardware and software virtually, among other things. On top of this, at the end you're left with a toolset that can be leveraged in the next product, making everything, as NASA once aspired to, "faster, cheaper, better".
This is of course a bit idealistic. No tool or set of tools can guarantee success. But in my own experience I've seen problems that were previously considered intractable solved to "engineering tolerance" by the application of MBD methods. And while there are many products simple enough that these methods are overkill, I can't help but feel that there are many categories, like drones, grid battery storage, or electric cars whose lives would be made vastly easier by a clearly defined MBD approach and execution. In fact, having a toolset with a good chance of getting from point A to point B could make some startups feasible where they wouldn't have been before.
This is where the titular question for this post comes in, is there a need in MBD for software stacks? I think so in spite of some reservations. The idea of winnowing down the available tools in the world to a simpler subset does bother me somewhat. After all, for all the criticisms leveled at the Mathworks monopoly in this area, how could I propose further selling them the farm? But ultimately, I don't think the choice is quite that limited. After all, web development has several sets of stacks; just because Mathworks can provide a full stack doesn't mean that it's the only solution.
So what might a stack look like? In the spirit of not reinventing the wheel, I've found several examples of stacks for HPC, so perhaps examining an example or two for an application slightly closer to MBD would help. Here is an example from Cray:
Another take on this idea is from ClusterTech, who sells an HPC software stack they've called CHESS:
So I've chosen these two examples for the multiple paths the Cray diagram shows and the inclusion of the hardware and application layers that ClusterTech's diagram shows. The multiple paths illustrate how to avoid a monopoly in a a particular step of the process. The inclusion of hardware and application layers illustrate how software doesn't exist in a vacuum, and both the platforms the software can run on and the applications it can be used for are ever expanding. Hardware stacks do exist, and while they're a bit outside of the scope of this discussion, it's certainly something to think about. This may be especially true if you're developing something like a control system where development might start on a desktop and end up on an embedded controller, or a simulator platform like dSpace.
So what might this look like for MBD? To make this a bit easier for me to get my head around, I'll fall back to a familiar subject: hybrid powertrain development. This is still very much a rough idea, so many finer details are left out, but better to start somewhere, right?
So in this rough draft, there's a few points I'd like to illustrate. The first is that not all these tools are compatible with every option. So, for instance, a macOS HPC environment is possible, but more likely than not it would be using a Linux OS. On top of that, if you're using one of the schedulers, then you're probably not using and Multidisciplinary Design Optimization (MDO) environment since they often include their own version of a scheduler. It's possible that you could have multiple jobs, each of which is performing their own MDO run, but at least in my own experience I would think this would be rare. I should also say that this is by no means a comprehensive or complete list, merely one that I thought would illustrate the main ideas of what might be included on an hybrid powertrain MBD stack.
Looking at this hypothetical stack, it's still pretty general. This could easily apply to aircraft or structural design, to name a few. I guess my question would then be, does this stack fork for more specific tasks? Is what we're looking for more of a tree, with the leaves being specific engineering projects? And is this exercise useful if everyone still has an individualized software (and/or hardware) stack?
As a mental exercise, I would say yes. Going through the process of making this rough draft, it really forced me to think about the progression of tools I would use to accomplish a task, instead of the mishmash of tools I've used in the past. And thinking of all the times when a project I've been on has had conflicts over what was essentially divergent software stacks, this would have been a great exercise to have done as a team from the beginning. And even if everyone does have their own stacks, having defined roles for each piece of software could still help teams that are just starting out understand what options they have and which path is most appealing. On top of this, if such an idea were to become widespread, then different pieces of software could narrow down to the specific roles expected of them, instead of trying to be jacks-of-all-trades, and perhaps even invest more into smooth interoperability.
I also feel like this exercise was a bit of a "periodic table" moment. By that I mean, by making this chart, it illustrated the holes and weaknesses of the software stack like how the first periodic tables pointed out missing and inconsistent elements. For instance, MDO environments are very much a mixed bag. I've used modeFRONTIER in the past and found its GUI to quickly descend into chaos, with very little explanation of things like optimizer options. I haven't used OpenMDAO, but it hasn't seen an update (from what I can tell) in over a year. I can't speak to HEEDS, but having more and better options for this part of the stack would be a great addition, especially if the optimizer toolsets were more interoperable.
In writing this post, I got to thinking about not just web development and the tools that make it a (relatively) quick, easy, and cheap proposition, but also game development. In fact, because of tools like Unreal and Unity, simple games can be pumped out in an afternoon, to both good and ill effect. These tools can produce a staggeringly diverse range of products. Unity, for instance, is behind Hearthstone, Pokemon GO, and Kerbal Space Program, which are a virtual card game, an augmented reality Pokemon game, and a space travel simulation game respectively. I can't help but feel that MBD having a similarly powerful stack would open up the range of new products and services that could be quickly and easily prototyped and deployed. Perhaps one day developing the next pacemaker, water filtration system, or carbon dioxide sequestration system will seem like app and web development do today; well within reach.