In systems engineering, we often focus on models, diagrams, and tools like CATIA Magic. But there’s a deeper question we rarely ask:

Do we all mean the same thing when we use the same words?

Now imagine a real MBSE project:

• 50+ engineers
• Multiple teams (hardware, software, systems, testing)
• Hundreds of diagrams
• Work happening over months

What starts happening:

1. One team writes “component” → means hardware
2. Another writes “component” → means software
3. Third team forgets to specify
4. Fourth team copies an old diagram

Now your system model has:

• Mixed meanings
• Hidden inconsistencies
• No single source of truth

And no one notices… until integration fails

however.........

This is not a documentation problem.
It’s not even a communication problem.

It’s a MEANING PROBLEM 

Because in systems engineering, words are not just words they define how the system is built, connected, and validated.

And when those meanings are not fixed:

• Models stop aligning
• Interfaces get misinterpreted
• Traceability breaks down

At small scale, this is manageable. At large scale, it becomes a risk.

What is Ontology (Really)?

Ontology is often explained as “defining terms.”

Ontology is a formal structure that defines what exists, how it relates, 

and what is allowed.

It has three core parts:

1. Classes (what exists)

• Component
• Function
• Interface
• Requirement

2. Relationships (how things connect)

• Component performs Function
• Component connects to Component
• Requirement isontology verified by Test

3. Constraints (what is allowed / not allowed)

• A Requirement must be verified
• A Function must be performed by a Component

• Invalid connections are not allowed

  Ontology is not just describing a system it is defining the rules of a valid system.

Mini Example: Flight Control System

Consider a simple flight control system.

Without ontology:

A model might show:

• Sensor → Actuator

At first glance, this may appear reasonable in a diagram.

With ontology:

The system is defined with clear relationships:

• Sensor provides data to Controller
• Controller commands Actuator

This naturally leads to the structure:

• Sensor → Controller → Actuator

Ontology helps ensure that system models are not only easy to create,
but also consistent, structured, and aligned with how the system is intended to work.

Pranav Kulkarni
Intern, Dassault Systèmes, India