Dear Readers,

I’m happy to announce, that I have just completed the writing of an overview/summary of the Arcadia model-based systems engineering method, which I published on my Github page. This was a tough one, especially considering the interesting structuring of the book (see my review about it), but it was well worth the effort.

So why invest a considerable amount of time into writing this summary? Simply because model-based systems engineering (MBSE) is something one can hardly go by without nowadays. Since there is the steady transition from the classic document-based systems engineering (DBSE) to MBSE, learning about it is time well spent. To understand why the transition is underway, let’s examine both approaches briefly.

DBSE tackles the problem of designing a system by producing a set of documents following a well defined method, like the V-Model. The left side of the “V” represents the decomposition of requirements and creation of system specifications, while the right side integration and validation. The left side produces a set of documents, each corresponding to one of the abstraction levels of the V. An example chain of documents can be:
Project requests –> Functional technical specification –> Architecture technical specification –> Component technical specification
The final product is a large set of somewhat connected documents.

Here are some limitations to this approach :

  • In order to keep coherence and consistency between all the documents, a considerable amount of work is needed to be invested in writing, reviewing and updating the various documents as the project progresses.
  • Requirements are captured using natural language and illustrations, but keeping consistency between them is difficult. Overspecification is a real danger.
  • Achieving traceability between high and low level design elements is very hard due to not having a well defined and enforced connection between such elements.
  • Communication of ideas is harder than need be, since information is spread out in several documents.
  • A wide set of tools is required to produce the documents: analysis tools, diagramming tools, publishing engines, document managers, etc.

MBSE on the other hand does not focus on producing documents (they are merely by-products), instead it aims to create a set of elements, where each element represents a requirement, a need, a behavior, an action, a component, an actor or pretty much anything related to the system. These elements are stored in a database and well defined relationships are formed for all of them within and between different engineering levels. This does not only guarantee a uniform representation of all concepts, components and architecture of the system, but also allows a uniform visualization by using standardized diagrams. Using such an approach guarantees consistency and traceability between all levels, but also allows an easier communication between all parties involved in the system design.

Of course, in order to be able to create a model, one requires a modeling language and a method. Fortunately, several options are available for both:

  • For the language there is
  • For the method one can choose from
    • Harmony-SE
    • INCOSE Object-Oriented SE (OOSEM)
    • IBM Rational Unified Process SE (RUP SE)
    • Vitech SE
    • JPL State Analysis (SA)
    • NATO Architecture Framework Methodology (NAF)
    • Dori Object-Process Methodology (OPM)
    • Arcadia
    • And possibly more

A good overview of most of these (with the exception of Arcadia and NAF) can be read in a JPL publication. Another good source is a fairly recent diploma thesis, which compares OOSEM/SysML with Arcadia/Capella. Finally, one can find out more about NAF in the official NATO publication.

It is rather clear by now that there are a fair amount of options available, and choosing between them is anything but simple. To cut a long story short, I chose Arcadia/Capella for the following reasons:
The method, language and associated development tool were developed

  • with each other in mind
  • based on the lessons learned from trying to use other methods/languages
  • using ideas from several other languages (NAF, SysML, AADL)
  • to be more straightforward than the others for engineers (quicker on-boarding)
  • to be general and not specific to any field
  • with the “blank paper syndrome” in mind
  • iteratively over several years (8), based on feedback from engineers working on different projects in different fields
  • by a large company (Thales) doing no-nonsense systems engineering (aerospace, transport, defence, security)

At the moment of course I don’t know if Arcadia will turn out to be the tool I expect it to be, but the above arguments seem to be pretty solid to give it a serious try, especially considering, that I don’t have the amount of time the Tales guys did to test out many other languages/methods to find out which is best for me. I simply trust their experience and judgement on the matter (and their need to develop their own tool and method despite already having many others available at the time) for now.

As always, thanks for reading.