Coming from hardware roots, we have an appetite for correct modeling of components within a system.

That is, our product is a subsystem within a system, and our subsystem, being our product, has subcomponents, all that we design under clear assumptions on our part, resolving a specific need encapsulated into the notion of a black box.

The whole thing looks a little bit archaic, but everyone whom has dealt with individual textual descriptions of requirements would understand that those boxes and connections promise sanity.


This way of looking at things, also particularly useful to software or hardware engineering, is formalized with model based system engineering, and the idea is lead by INCOSE, and they have a nifty handbook for the whole idea.

There are many tools available for MBSE (Model Based System Engineering)  and many of them have pretty prohibitive price tags for startup use. That aside, alternatives to them radiate the expensive need to have a grasp of SysML or something equivalent, which, I don't have a formal education of. So, there is a fiscal and educational deficiency on our part to extensively make use of the fruit that modeling bears for us.

I have been scrounging for a solution while we were making a leap towards automotive electronics, and  I have found a project, then spearheaded by Thales, Capella. It is an Eclipse based open source MBSE software that also incorporates the educational elements within the program itself. That is how, with the help of video lectures, books  and sample models, I feel that I have found the calm waters that I need to get a hang of modeling. I think of it not only as a industry-proven modeling workbench, but also a recruitment tool to have people on board on modeling.

A work-in-progress physical architecture diagram, one of the latter steps of system engineering.

Although the specific points still have some system engineering lingo, the main idea is clear. You go downwards, upwards, or you can roller-coaster through different levels of the system that are concerned with:

  • What the users of the system need to accomplish
  • What the system must accomplish for the users
  • How the system will work to fulfill expectations
  • How the system will be built

So you say, a startup, and MBSE?

My current interests are double fold. System or hardware engineers are stuck on top of a ever rattling product-market-fit seeking missile, but they have an impulsive need for systematic perfection of a Swiss timepiece movement. First, seemingly, the lean startup methodology that many swear on, the speedy virtuous circle of build-measure-learn, conflicts with the error-averse background of model based system engineering.  At least, the main needs that are addressed are by them are considerably distant from each other.