Problem Summary ⚠️
The core problem is that a single physical component can expose multiple independent controllable degrees of freedom (DoFs) (e.g., landing gear: extension + steering + braking), but the current way of working with CPACS assumes “one component uID ↔ one DoF to be controlled via controlParameter”. This breaks down as soon as more than one controlParameter is needed per component.
For a long time, the only controllable components in CPACS were controlSurfaces (see Figure below). These were therefore referred to as controlDevice, which contain a path definition along which the control surface can move. In this case, a hingeLine is defined that can be translated and rotated. This definition maps the physical transformation (in degree and meter) to an abstract controlParameter.
To realize a specific state of such component/device for further analysis, a controlParameter was then assigned to the corresponding component via its uID, in this case the uID of the trailing edge. The classic example is controlDistributors, which allow multiple components to be controlled simultaneously. A newer implementation is controlDefinitions in which multiple states of components can be combined.
However, when developing new controllable components, it became apparent that these can have several adjustable paths. For example, landing gear can be extended and retracted, steered, or braked. Propellers can be pitched, their RPM controlled, and the mixture adjusted.
The concept of referencing a component via its uID and specifying a controlParameter no longer works, as several controlParameters may be necessary per component. The reference should therefore no longer point only to the component itself, but to one of its control definitions. The question therefore is:
How do we name the combination of multiple control definitions at the component level and how do we reference them?
Below is a list of current implementations in CPACS. Other use cases involve tiltable rotors (#852) or foldable wingtips (#831). We should therefore strive for consistent naming in CPACS.
We could say that controlDevice refers to general control instruction; for example, the steering of a landingGear. The hierarchy of this control instruction indicates which landing gear is affected. I must admit it is a bit counterintuitive to talk about controlDevice when referring to a control definition (one would think this is the uID of the landingGear), but we would avoid a major braking change for all nodes that reference such components (controlDistributors, controlDefinitions, aeroPerformanceMaps, etc.).
If it is too counterintuitive, we will have to bite the bullet and rename it in view of future additions that require multiple control functions. For example, controlStates, controlFunctions, etc.
List of current implementations
landingGear with extensionPath, steeringPath, brakingState and two general parameters like the reactAngle and offset. This is a good example that a single component can have multiple paths.
- The state of a system is described as
state, specifying a control parameter for active and inactive state.
- And, of course, the classic implementation of control surfaces:
For a long time, the only controllable components in CPACS were
controlSurfaces(see Figure below). These were therefore referred to ascontrolDevice, which contain apathdefinition along which the control surface can move. In this case, ahingeLineis defined that can be translated and rotated. This definition maps the physicaltransformation(in degree and meter) to an abstractcontrolParameter.To realize a specific state of such component/device for further analysis, a
controlParameterwas then assigned to the corresponding component via itsuID, in this case theuIDof the trailing edge. The classic example iscontrolDistributors, which allow multiple components to be controlled simultaneously. A newer implementation iscontrolDefinitionsin which multiple states of components can be combined.However, when developing new controllable components, it became apparent that these can have several adjustable paths. For example, landing gear can be extended and retracted, steered, or braked. Propellers can be pitched, their RPM controlled, and the mixture adjusted.
The concept of referencing a component via its
uIDand specifying acontrolParameterno longer works, as severalcontrolParameters may be necessary per component. The reference should therefore no longer point only to the component itself, but to one of its control definitions. The question therefore is:How do we name the combination of multiple control definitions at the component level and how do we reference them?
Below is a list of current implementations in CPACS. Other use cases involve tiltable rotors (#852) or foldable wingtips (#831). We should therefore strive for consistent naming in CPACS.
We could say that
controlDevicerefers to general control instruction; for example, the steering of alandingGear. The hierarchy of this control instruction indicates which landing gear is affected. I must admit it is a bit counterintuitive to talk aboutcontrolDevicewhen referring to a control definition (one would think this is theuIDof thelandingGear), but we would avoid a major braking change for all nodes that reference such components (controlDistributors,controlDefinitions,aeroPerformanceMaps, etc.).If it is too counterintuitive, we will have to bite the bullet and rename it in view of future additions that require multiple control functions. For example,
controlStates,controlFunctions, etc.List of current implementations
landingGearwithextensionPath,steeringPath,brakingStateand two general parameters like thereactAngleandoffset. This is a good example that a single component can have multiple paths.state, specifying a control parameter for active and inactive state.