systemArchitectures: specify type of connection

[MarAlder]

with transmissionType:

<xsd:restriction base="stringBaseType">
    <xsd:enumeration value="massFlow"/>
    <xsd:enumeration value="heatFlow"/>
    <xsd:enumeration value="electricPower"/>
    <xsd:enumeration value="mechanicalPower"/>
</xsd:restriction>

@jbussemaker, @TimBurschyk

[jbussemaker]

Nice to see this!

Some recommendations:

• I would call it connectionType, it's a bit more general and maybe "transmission" can be interpreted as something related to gearboxes already
• Enumeration type is good of course, but I would also allow users to specify their own types (simple as a string)
• I'm not sure if it would make sense to add a unit (kg/s, W, etc.) to the connection node (so as a sibling of connectionType), or that this rather makes sense for the analysis results only

Some additional connection types off the top of my head:

• hydraulicPower
• data, signal (important for modeling cyber-physical systems)
• More specific massFlows: airFlow, liquidFlow, gasFlow
• physicalConnection
• force, pressure

[MarAlder]

* I would call it `connectionType`, it's a bit more general and maybe "transmission" can be interpreted as something related to gearboxes already

ok, this is fine for me

* Enumeration type is good of course, but I would also allow users to specify their own types (simple as a string)

I am not a friend of this. According to the CPACS philosophy we should try to keep the data model as explicit as possible to enable automated processing. The receiver of the data wants to know what kind of strings he can expect according to the schema.

* I'm not sure if it would make sense to add a unit (kg/s, W, etc.) to the connection node (so as a sibling of `connectionType`), or that this rather makes sense for the analysis results only

Since this is only about the type, I suggest leaving the quantitative values and their units to the powerBreakdown.

[TimBurschyk]

Thanks for adding the type of connection! Here are my thoughts:

• I agree with @jbussemaker that connectionType fits better and follows the proposed structure connections/connection/connectionType
• is the connectionType optional or should it be?
• I would not include units within the connectionType, because I think it should be part of the analysis only
• If I got you correctly @MarAlder, the connectionType is linked with the types defined in the analysis. The question which pops up is: how specific should the type be? A mass flow can be air, gas, hydraulic oil... do we need to specify this directly and should it be linked to the options within the powerBreakdown?

[jbussemaker]

The original idea of including connectionType is to distinguish between different types of connections between the same pairs of sources and targets. For example, there could be some physical connection as well as data/signal connection at the same time.

As this might not always be needed for all cases, I would say connectionType can be optional.

[MarAlder]

• Occurence: Ok, the node will be optional.
• Values: My only request is that we provide a restricted list possible values. No need for linking or something, just tried to align with the powerBreakdown. Just provide me a list, which avoids too much redundancy (e.g., signal could be everything)

[jbussemaker]

All right, then I recommend at least the following:

• All values from powerBreakdown
• hydraulicPower
• informationFlow
• physicalConnection