Spacecraft Engineering Models: How to Migrate UML to TypeQL

How to map UML to TypeQL. Read how the European Space Agency migrated their spacecraft engineering models from UML to TypeQL for use in a TypeDB database.

Goal: Migrate the UML-based engineering model of a spacecraft to TypeQL

Why Do This Migration in the First Place?

The lifecycle of a spacecraft is roughly divided into seven consecutive design phases. Part of the early design phases deals with the feasibility of the intended mission. Feasibility is identified by assessing each design aspect that is needed to accomplish the specific mission.

This requires that engineers lay out all possible design options and iteratively go through them in relation to all the other engineering design options. Ultimately ending up with a sound system solution.

This requires various experts across domains to be reporting into and checking against a central engineering model. This design process is called concurrent engineering. 

“A spacecraft is a complex puzzle of subsystems. Concurrent Engineering is a design process enhancing communication between experts and accelerating the convergence towards a sound design solution.”

Each expert needs to report their design architecture into a central engineering model. This then becomes the blueprint for the spacecraft. Each design has a project tree comprised of all the components of a particular aspect of the space mission.

This quickly becomes a lot of information to organize, maintain, and keep track of. The structure of this blueprint is defined by European space standards — ECSS-E-TM-10–25A — provided in a UML class diagram.

Over time, more and more engineering models are created. However, these models are disparate, making it challenging for engineers to make use of them as a collective source of information to be used over time. To enhance the data linkage, reusability, and interpretability of stand-alone models, the need to merge the models into one database becomes clear. This then allows for the mining of information within the models, comparisons between them, and the ability to infer new knowledge from them.

Why a Knowledge Graph and not a SQL database?

SQL databases aren’t built to represent relationships in your data and, for the most part, don’t handle heterogeneous and unstructured data well.

Since Audrey’s team’s goal is to mine and discover information within the models, a database that can model relations naturally and aid in inferring new knowledge is needed.

To get the inference they were looking for, a schema that included the ability to define rules was an important requirement. “Without a schema to structure the database, there is no rule-based reasoning, thus no inference.”

Once the team noted the requirements they were looking for in a database, they set out to find a suitable one.

Researching the landscape, they noted quite a few options: Neo4J, Stardog, AllegroGraph, AnzoGraph, TigerGraph, and TypeDB.

The parameters for making their decision were:

• OS portability: other evaluated databases were only available on Linux systems, and they needed to allow engineers to work with OS or Windows as well as Linux.
• Learning Curve: as their team didn’t have a background in RDF, they felt it would be easier and faster to learn one language or tool vs. the multitude of Semantic Web Technologies.
• Scalability: they didn’t want to be limited by the database in the number of nodes and relations.
• Inference Engine: does the database allow for inference without requiring the development or integration of another tool?
• Visualization: is there a visualizer available?
• Support: what do the community and formal support look like for the database
• Licensing: as their team is part of the University of Strathclyde, the availability of an open-source version was preferred.

Ultimately, the team chooses Vaticle’s TypeDB for the simplicity of the language — making onboarding easier and faster for engineers — the integrated reasoning engine, the presence of a strong community that is active and supports each other, and the availability of an open-source version.

How to Migrate UML to TypeQL

A Brief Introduction to UML
Unified Modelling Language (UML): a standardized Object-Oriented (OO) modeling language for specifying, visualizing, constructing, and documenting software systems.

The building blocks of a class diagram in UML are:

• Class: describes a set of objects sharing the same features/constraints/semantics (mapped as an entity in TypeDB schema)
• Interface: a non-instantiable class declaring features to be implemented by another class (mapped as an abstract type in TypeDB schema)
• Property: a structural feature of a class representing an attribute or the end of a relationship (mapped as an attribute in TypeDB schema)
• Relationship: links one or more classes — there are multiple relation types as well: association, generalization, dependency, etc. (mapped as relations in TypeDB schema)

Migrating Spacecraft Engineering UML to TypeDB

There are two main steps to migrating an engineering model in UML to TypeDB: defining a schema in TypeQL and inserting data into TypeDB.

Defining a Schema
TypeDB is a direct implementation of the Entity-Relation diagram and makes Entities, Attributes, and Relations first-class citizens of the database.

As noted above, we map a UML class to a TypeDB entity, a UML property to a TypeDB attribute, and a UML relation to a relation in TypeDB. The schema is also where we can define the rules for the reasoning engine.

UML Class to TypeDB Entity
Starting with the mapping of a UML class to a TypeDB entity, the first thing to note is that TypeDB allows for type inheritance.

In the team’s UML model, they have a class called a Mixin, which is a class containing methods (attributes and roles) for use by other classes. These Mixin classes are not migrated, but instead, the attributes and role types are redefined for each of their “child” classes — TypeDB’s type inference comes in handy here. In TypeDB this means they are defined as attributes and role players owned or played by entities (classes).

For the abstract classes, an abstract entity is defined. For concrete classes, a standard entity is defined. Each of these may have Mixin and non-Mixin classes, mapped as noted in the paragraph above.

Looking at the example in the image below, we see that a Person is a subclass of four other classes. Three of these:

shortnamedthing

,

namedthing

, and

deprecatablething

 , are Mixin’s. While Thing is a concrete class. We redefine the three Mixin’s as attributes of the person entity, and using the TypeQL keyword sub; we define it as a subtype of thing.

UML Property to TypeDB Attribute

A UML property can be an attribute (value type) — defined as an attribute in the schema — or the end of a relation (reference type) — defined as a role in the schema. Additionally, the UML property is either directly owned by the class or inherited from another class.

In the case that a property is inherited from another class, it can inherit from a Mixin class or a non-Mixin class. When it is inherited from a non-Mixin class, we define the inheritance from the parent entity within the TypeDB schema.

The example above shows all the attributes in the UML Diagram User Manual are defined as attributes owned by the person entity type. We also see an example of how we would define these using TypeQL (TypeDB’s query language) in the console:

define givenName sub attribute, value string; surname sub attribute, value string; organizationalUnit sub attribute, value string; isActive sub attribute, value boolean;

UML Relationships to TypeDB Relations
The mapping of a UML relationship to a relation in a TypeDB schema is a bit more nuanced. As there are multiple types of relationships in UML, there are some decisions to make in how to map to a TypeDB schema. For Audrey’s team, they were working with just two types of UML relationships: association relationships and composition relationships. For these, their mapping decision was to use different naming conventions in their TypeDB schema: reference and containment relation types, respectively.

As we see in the example below, we need to define the relation type and the role type that is being played by the entity.

Inserting Data
Exporting the engineering models as JSON files, we are able to map this JSON file to the TypeDB schema and build an insert query to get it into TypeDB. This is done via migration pipeline templates that take each element found in the JSON file and look at the class type. Each class type has its own template, which then builds the TypeQL insert queries. We can see an example of one such template below.

Where is This Method Currently Being Applied?

The migration was applied to three Engineering Models, including two internal CubeSat models. This early implementation already demonstrated the power of using TypeDB as a knowledge graph for this use case. Tasks commonly performed by engineers such as mass budget computation could be automated, and TypeDB provided new insights into the data, enabling the quick recall of similar missions.

Thank you and Some Helpful Links

We appreciate Audrey and her team for their hard work and for taking the time to put together this presentation. The TypeDB community looks forward to having her back to share the progress and future work with the European Space Agency, the University of Strathclyde, RHEA Systems B.V. and Airbus within the Networking/Partnering Initiative (NPI). 

• Watch the full presentation replay on YouTube
• Dig into TypeDB further via GitHub
• Reach out to Audrey and the Vaticle team on the TypeDB community Discord

Related Stories

Tags

Join Hacker Noon

Create your free account to unlock your custom reading experience.

Spacecraft Engineering Models: How to Migrate UML to TypeQL
Source: Super Trending News PH