Combining system definitions: powerBreakdowns

MarAlder commented 2 years ago

This is a sub-issue to #721 which aims at merging the system breakdowns from the projects Exact and Avacon.

There had been some initial discussions with the developers of the corresonding proposals. As a next iteration step, both approaches were merged into one schema, which can now be further elaborated in detail. The following is an overall summary of the current status and a few explanations:

html docs

Current status

powerBreakdown

Multiple cases

The current assumption is to allow for multiple breakdowns which can refer to different trajectories. We typically use the term case when trying to establish naming conventions. Maybe powerBreakdownCases is perhaps a bit too much of a good thing, so the current proposal says

grafik

<powerBreakdowns>
    <powerBreakdownCase uID="randomUID39483"/>
    <powerBreakdownCase uID="randomUID34242"/>
<powerBreakdowns>

Case setup

According to this development guidelines each case has the typical set-up consisting of name, description (optional), specification and powerBreakdownData: grafik

Breakdown of data

In contrast to the massBreakdown the sum of the values is optional. We think these can be derived from summing up the child elements.

Grouping [1..inf] system elements into systems is not necessary. However, we might allow ourselves this additional level of hierarchy to simplify looping over these elements and have a somewhat clearer structure. Also, it would be consistent with a variety of cases where we track the plural/singular combination.

grafik

"At least one of" construct

You may wonder what this strange Choice element is doing here. In XML this is the approach to say that at least one of the elements must be present. Look at the occurence (dashed line = optional; solid line = mandatory) and notice that it actually makes sense 😏 Please check if it also makes sense for your use-cases to allow for this subdivision.

grafik

Floats and vectors

nominalValues are just single numbers and trajectoryValues are vectors:

grafik

Categories: To be ATA chapter or not to be ATA chapter...

The proposal allows for a list of system elements which can be assigned to ATA chapters via the category element, but don't need to (<category>unspecified</category> or <category>remainingContribution</category>). grafik

grafik

Further breakdown into components

If we allow for a breakdown into components, this could look like below. Note that component is a component of the current system, even if it can be a system itself (please no philosophical discussions at this point...)

grafik

Location of components

To specify for example heat sources it might be useful to specify the components location. This could be done by linking a component in aircraft/model/systems/... or directly specifying x,y,z coordinates. The latter is treated as an additional information for this analyses result and must not be used as a systems modeling approach!

Next steps:

[ ] Agree on/Find better element namings
[ ] Check for harmonization with Imothep's systemTrajectories proposal, as it is quite similar (#721)

MarAlder commented 2 years ago

A result of a first discussion:

The schema allows to specify multiple system nodes of category ata21. In combination with the components element it would therefore be two possible to model a more detailed breakdown of ATA 21 in two different ways: (1) by defining more than one system element with category ata21 or (2) defining a single system element of category ata21 and multiple components having again nominalValues or trajectoryValues.

To avoid this redundancy we propose to only allow for option (1) and remove the ...Values element from components. However, maybe we keep the components element to provide some more detailed explicit information on the components under consideration (which should be modeled under aircraft/model/systems/...).

Edit: Simplified to list of component uIDs to avoid misuse of systems modeling in analysis node. Edit 2: List of component uIDs set to optional.

grafik

Example

<systems>
    <system>
        <category>ata21</category>
        <description>Left pack</description>
        <nominalValues>
            <pneumaticPower>1.23</pneumaticPower>
        </nominalValues>
        <componentUIDs>
            <uID>pipe1UID</uID>
            <uID>pipe2UID</uID>
            <uID>valve1UID</uID>
        </componentUIDs>
    </system>
    <system>
        <category>ata21</category>
        <description>Right pack</description>
        <nominalValues>
            <pneumaticPower>1.23</pneumaticPower>
        </nominalValues>
        <componentUIDs>
            <uID>pipe3UID</uID>
            <uID>pipe4UID</uID>
            <uID>valve2UID</uID>
        </componentUIDs>
    </system>
</systems>

This rises another open issue:

[ ] How can we explicitly say that ata21 is fully covered by the data-set? From the point of view of the data format, it is perfectly permissible to exchange information on only a part of the overall system. Somehow, however, this should be made visible to the recipient of the data.

YaCabac commented 2 years ago

I really like the current status! I also appreciate the simplification concerning the component uIDs. However, I propose to make the componentsUDIs optional. Hence, components can be linked, e.g. to get components locations etc. But is not required if we don't need any location data. What do you think of that?

I also support the idea to somehow mark whether a system is described completly or not. Additionally, powerValues may have attributes in future. Maybe we can formulate this as a futher issue?

MarAlder commented 10 months ago

I think we have it. Thanks @TimBurschyk for this enhancement.

DLR-SL / CPACS