Support special connections

[eidekrist]

We need a way to describe and validate special connections like:

• Sum connection (target = sum of sources)
• Transforms and rotations
• Linear transforms (y = ax + b) for e.g. unit conversions

The format in cse-config.json could be something like:

"specialConnections": [
    {
      "type": "sum",
      "sources": [
        {
          "simulator": "Thruster1",
          "plug": "Force"
        },
        {
          "simulator": "Thruster2",
          "plug": "Force"
        }
      ],
      "targets": [
        {
          "simulator": "Hull",
          "socket": "ThrusterForces"
        }
      ]
    }
  ]

This example may however be too generic in order to properly describe a transform etc.

[mrindar]

So a special connection can have a set of plugs and variables IN and a set of variables and sockets OUT?

I think we should rename this thing, because they are not really connections. They are performing some calculation on its inputs to produce some outputs, so they are more like, manipulators, fuctions, modifiers, etc.

[eidekrist]

So a special connection can have a set of plugs and variables IN and a set of variables and sockets OUT?

Yes, that would be the base definition if this PR gets approved :-)

I think we should rename this thing, because they are not really connections. They are performing some calculation on its inputs to produce some outputs, so they are more like, manipulators, fuctions, modifiers, etc.

I would argue that they still are connections, but do something else (calculation, routing etc) as well. Names are difficult, so I suggest we hammer out the concept first, then find a suiting name once we have a clear picture of what we're looking at.

What's in a name? That which we call a rose By any other name would smell as sweet;

-Shakespeare

[mrindar]

I suspect you assign them the name 'connection' because of existing software architectural reasons.

The current framework we have in the ontology to work with connection on the plug/socket level is:

1. A plug->socket connection must be between a plug and socket of same type
2. A plug can be connected to many sockets
3. A socket can only be connected to one plug

With these building blocks we are not able to represent your example specialConnection, so we have to extend the ontology. My initial idea (@2r5345gwa is the authority on this though) is that we create a class block in the ontology which generically have a set of sockets and plugs. We can then have different subclasses of this block class, for instance sum_block, which will add restrictions on its sockets and plugs. For instance, all sockets belonging to class sum_block must be of the same type, and it can only have one plug, also of the same type as the sockets. When we see a specialConnection block in the cse-config.json, we will generate an individual of a sum_block with sockets: Thruster1.Force and Thruster2.Force, and plugs: Hull.ThrusterForces. Then we can take the plug and socket individuals from the models, and connect them to the plugs and sockets of the sum_block individual.

Something like this:

+-----------+                                    +-----------+
|           |                                    |           |
| Thruster1 | --force_plug-->  >--force_socket-- |           |
|           |                                    |           |                                    +------+
+-----------+                                    |           |                                    |      |
                                                 | SUM BLOCK | --force_plug-->  >--force_socket-- | Hull |
+-----------+                                    |           |                                    |      |
|           |                                    |           |                                    +------+
| Thruster2 | --force_plug-->  >--force_socket-- |           |
|           |                                    |           |
+-----------+                                    +-----------+

Every named object in the figure, is an individual in the ontology and the --> >-- parts represents a has_connector_mate object property in the ontology. This is something that we could generate based on your specialConnection example and run the reasoner on. The missing part of the ontology is stuff related to restrictions on the SUM BLOCK.

[eidekrist]

Very nice!! This makes a lot of sense. I see what you mean about connections now, good point!