Some thoughts on development standards

A few thoughts I got from previous discussion on CPACS data modeling standards (open for discussion). What do you thing about the guidelines proposed below and do you have further ideas?

Redundancy

What do we mean by redundancy? Is the repeated specification of data such as the proposed flightPoint/state/case (atmosphere, altitude, velocity) in #694 critical? In my opinion a set of velocity/altitude itself it is not a property dedicated to a specific aircraft/rotorcraft per se, thus making it a vehicle independent information. Therefore, (1st) the information could theoretically be outsourced to higher hierarchy levels (cpacs or cpacs/vehicles) and (2nd) a multiple specification of this information does not fall within the scope of data redundancy. Although the above example fulfills both requirements, should we always split the data into different hierarchical levels? To guide these decisions we should agree on some more development guidelines. I propose:

Development guideline §1: Vehicle-dependet information must follow the single-source-of-truth principle and must therefore be unique and explicit.
Development guideline §2: (Vehicle-) independent information should be placed into higher hierarchical levels and linked via uID, if the definition is so complex or if it is used so frequently that the benefits from avoiding redefinitions and increasing consistency overweigh the increased complexity by splitting data and by the fact that the outsourced data must be processible by the linking elements.

A good example for §2 is the missionDefinition. It is vehicle independent and so complex that outsourcing it from vehicles/aircraft/model to cpacs/performanceCases reduces redefinitions and therefore also increases consistency (we are linking to the same, so we can be sure we are talking about the same). However, all elements linking the mission definition (and thus all tools processing the linking elements) should be able to process the way these missions are defined via segmentBlocks, segments, parameter lapses and all the fancy things we have in the mission definition.

Hierarchical classification of data

In cases where §2 applies, the question arises at which level data should be specified. I noticed that we often assume a CPACS philosophy such as all repetitive elements are always defined in the plural singular form (e.g., wings/wing). At the same time, we would like to follow the approach of going from the System-of-Systems level (e.g, airports, fleets, etc.) further and further into detail, i.e. down to small components of an aircraft structure (e.g., ribs, spars). Again, the example of the missionDefinition reveals that the two approaches can be in conflict, because it is independent from a specific vehicle, but it is not really representing a system which can be seen as alternative to vehicles. That is why I propose to treat the plural containers such as vehicles more as a grouping element (e.g., *everything I want to relate to the system level vehicle):

Development guideline §3: Plural elements in CPACS are intended to group all information belonging to the same thing at a specific system level.

One thing to group under such a plural element is of course a list of multiple single instances (e.g., 1 to infinite models, wings and so on), but also all the information belonging to this element at the very system level. In general, we are already quite consistent in following this assumption by defining that a system-of-system is composed of vehicles, airports, airlines and the corresponding information such as flights or studies. The vehicle as one part of the overall system-of-system is a group of aircraft, helicopter as well as the corresponding information such as generic profiles, materials and so on. We could also group the latter under aircraft or helicopter, but from §2 we may conclude that the benefit of reusing these (sometimes called library elements) multiple times within aircraft and helicopter is large and so we group everything under vehicles. However, should performanceCases (including missionDefinitions) better be grouped under vehicles? That's maybe a topic for CPACS 4.0. grafik

Naming conventions

We should strive for consistent nomenclature with dedicated meanings in CPACS. #694 and #695 are recent issues. For example, what do we mean when we're using terms like flightPoint, case or state? I don't want to commit at this point, but we should set guidelines here, such as:

point: Information specified in space or time or more abstract parameter spaces?
case: used for complex grouping of analysis inputs and results (e.g., loadCase, divergenceCase, aeroCase, performanceCase, operationalCase and certificationCase in weightAndBalance, etc.)
state: the state properties of a thing, e.g., the flightPoint along with angleOfAttack, velocities, etc.

Examples like this should be collected in a dictionary. A corresponding development guideline could refer to this:

Development guideline §4: Naming of elements should be done in accordance with dictionary XYZ.

Furthermore, we should avoid using mathematical symbols or abbreviations as their meaning might differ between disciplines (see for example #695):

Development guideline §5: Element names should be descriptive avoiding abbreviations or mathematical symbols if possible.

There are cases where this is hardly possible and should be avoided if element names would become too long, e.g., aerodynamic roll derivatives along various axes in the aeroPerformanceMap.

DLR-SL / CPACS