Refine `decks` to better align with `systems`

[MarAlder]

We propose several modifications to the decks definition to improve consistency with systems.

This issue concerns the following XPaths:

• pre-defined deck elements: capcs/vehicles/deckElements
• actual deck definition at aircraft level: cpacs/vehicles/aircraft/model/fuselages/fuselage/decks

Problem description

The definitions of deckElements and systemElements have always been similar, but not fully aligned. With the introduction of the new systems in v3.5, the nodes for deckElements and systemElements were already brought closer together. However, this still left some ambiguity, for example by combining a boundingBox in the decks definition with cuboid-based shapes in the systems definition. As a result, it is not entirely clear what the difference is and when each approach should be used.

In addition, the systems definition now needs an update based on first practical experience. The proposed changes are described in #858 and #848. Some of the lessons learned there are equally relevant for the decks definition.

We therefore aim for a consistent implementation of both definitions, also with future similar extensions in mind, such as payloads.

Details

For the details of these changes, you may compare the online documentation:

• current official release version:

  • deckElements
  • deck definition at at aircraft level

• proposed updated version:

  • deckElements
  • deck definition at at aircraft level

• A TiGL implementation is available to verify the schema extensions: Decks DLR-SC/tigl#1298

Summary of proposed changes

Pre-defined deck elements

Essentially all points from #848 apply to the deck elements as well. In particular, this means:

• Geometry is described via combinations of: cuboids, cylinders, cones, ellipsoids, multiSegmentShapes, and externals (link to CAD files)

• The boundingBox element will be removed. Instead, we introduce an attribute representation with the possible values physical (default, if not given) and envelope (see also Modify primitive geometry definition for systems and decks #848). For example:

    <seatElement uID="predSeatElement">
        <name>Predefined seat element</name>
        <geometry representation="envelope">
            <cuboids>
                <cuboid>
                    <lengthX>0.8</lengthX>
                    <depthY>2.0</depthY>
                    <heightZ>1</heightZ>
                    <transformation>
                        <translation>
                            <x>0.2</x>
                        </translation>
                    </transformation>
                </cuboid>
            </cuboids>
            <transformation>
                <translation>
                    <x>0.3</x>
                </translation>
            </transformation>
        </geometry>
    </seatElement>

• We also propose using the same geometry definition for cargoContainerElements instead of keeping an individual parametrization. Since the new proposal allows combining components, it provides a more flexible way to define geometry. An example implementation could look like:

    <cargoContainerElement uID="predCargoContainer">
        <name>Predefined cargo container</name>
        <geometry>
            <cuboids>
                <cuboid>
                    <lengthX>2</lengthX>
                    <depthY>1</depthY>
                    <heightZ>0.7</heightZ>
                    <upperFaceYmin>0</upperFaceYmin>
                    <upperFaceYmax>1.5</upperFaceYmax>
                </cuboid>
                <cuboid>
                    <lengthX>2</lengthX>
                    <depthY>1.5</depthY>
                    <heightZ>0.7</heightZ>
                    <transformation>
                        <translation>
                            <z>0.7</z>
                        </translation>
                    </transformation>
                </cuboid>
            </cuboids>
        </geometry>
    </cargoContainerElement>

Instantiation of elements at deck level

Transition from 2D to 3D base types

Currently, many components are defined as deckComponent2DBaseType, following the idea that such elements are positioned on the deck floor using only x and y, and rotated around z. This is described by @jnwalther in [Walther et al.](https://elib.dlr.de/189457/1/s13272-022-00610-5.pdf).

One concern with the 2D base type is that scaling is only defined in x and y, which creates ambiguity about what should happen in z. Furthermore, the implementation may become problematic if the deck floor is not fully planar, in which case a z transformation could be required.

We therefore propose to consistently use deckComponentBaseType for all deck elements. This is backwards compatible, since planar transformations can still be represented by varying only x and y, while z remains available for special cases. It also simplifies the schema implementation.

⚠️ Open discussion point: scaling at aircraft level?

The systems community decided against having a scaling element at aircraft level. #858 explains:

The main reason is that the physical implications of scaling are not sufficiently clear, particularly with respect to mass, center of gravity, and inertia properties. We therefore propose following a stricter rule: if a component of a different size is required, it should be defined as a new pre-defined systemElement rather than obtained by scaling an existing one.

• Decision needed: should we adopt this in the decks definition, or are there reasons for scaling of deck elements during instantiation?

ℹ️ Feedback from the cabin community is that scaling is still needed on instantiation level.