From cdd0840a4c1d180dfcb0d54ddb2ca8359b62239d Mon Sep 17 00:00:00 2001 From: Alder Date: Tue, 19 Dec 2023 21:54:07 +0100 Subject: [PATCH] fix wrong indentations due to XML pretty print --- schema/cpacs_schema.xsd | 1938 ++++++++++----------------------------- 1 file changed, 491 insertions(+), 1447 deletions(-) diff --git a/schema/cpacs_schema.xsd b/schema/cpacs_schema.xsd index f99a938..c4a968b 100644 --- a/schema/cpacs_schema.xsd +++ b/schema/cpacs_schema.xsd @@ -45,68 +45,46 @@ cpacs@dlr.de Version - V3.5-RC + V3.5 Date - 2023-11-17 + 2023-12-19 1. Overview - The - C - ommon - P - arametric - A - ircraft - C - onfiguration - S - cheme - (CPACS) - is an XML-based data format for describing aircraft configurations and their corresponding data. + The Common + Parametric + Aircraft + Configuration + Scheme + (CPACS) is an XML-based data format for describing aircraft configurations and their corresponding data. - This XMfL-Schema document ( - XSD - ) serves two purposes: (1) it defines the - CPACS - data structure used in the - XML - file (e.g., aircraft.xml) and - (2) it provides the corresponding documentation (see picture below). An XML processor (e.g., + This XML-Schema document (XSD) serves two purposes: + (1) it defines the CPACS data structure used in the XML file (e.g., aircraft.xml) and + (2) it provides the corresponding documentation (see picture below). + An XML processor (e.g., TiXI https://github.com/DLR-SC/tixi - or - XML tools in Eclipse) parses the XSD and XML files and validates whether the data set defined by the user (or tool) conforms to the given structure defined by the schema. + or XML tools in Eclipse) parses the XSD and XML files and validates whether the data set defined by the user (or tool) conforms to the given structure defined by the schema. - This documentation explains the - elements - defined in - CPACS - and its corresponding - data types - . - Data types can either be - simple types - (string, double, boolean, etc.) or - complex types - (definition of attributes and sub-elements to build a hierarchical - structure). In addition, the sequence of the elements and their occurrence is documented. + This documentation explains the elements defined in CPACS and its corresponding data types. + Data types can either be simple types (string, double, boolean, etc.) or complex types (definition of attributes and sub-elements to build a hierarchical structure). + In addition, the sequence of the elements and their occurrence is documented. To link the XML file to the XSD file, the header of the XML file should specify the path of the schema file. - An example could look like this: + An example could look like this: German Aerospace Center (DLR e.V.) https://www.dlr.de/ - - . For further information please visit + . For further information please visit www.cpacs.de https://www.cpacs.de - - . + . @@ -133,22 +109,14 @@ cpacs@dlr.de 2. Data structure - CPACS data is modeled in a hierarchical structure whose underlying concept follows a top-down description of a system-of-systems which decomposes a generic concept (e.g., an - aircraft - or - rotorcraft - ) into a more detailed description of its components. This originates from the conceptual and preliminary design of aircraft, where the level of detail is initially low and continues to increase as the design process progresses. + CPACS data is modeled in a hierarchical structure whose underlying concept follows a top-down description of a system-of-systems which decomposes a generic concept + (e.g., an aircraft or rotorcraft) into a more detailed description of its components. + This originates from the conceptual and preliminary design of aircraft, where the level of detail is initially low and continues to increase as the design process progresses. - For some concepts within - CPACS - , however, a bottom-up approach is applied where the components are first defined in detail (sometimes referred to as - library - ) and then linked within an instantiated higher-level concept. This is advantageous when used multiple times within complex systems, such as - engines - , which only have to be defined once in order to be referenced several times on the - aircraft - . The combination of these two methodologies is known as middle-out approach and enables the goal to fully parametrize aeronautical systems. + For some concepts within CPACS, however, a bottom-up approach is applied where the components are first defined in detail (sometimes referred to as library) and then linked within an instantiated higher-level concept. + This is advantageous when used multiple times within complex systems, such as engines, which only have to be defined once in order to be referenced several times on the aircraft. + The combination of these two methodologies is known as middle-out approach and enables the goal to fully parametrize aeronautical systems. @@ -162,50 +130,36 @@ cpacs@dlr.de 3.1. CPACS coordinate system - Coordinate systems are a regular cause for ambiguous interpretation of data. In - CPACS - , the reference coordinate system is the - CPACS - -coordinate system. This coordinate system is used for most of the data. A single exception is made in order to keep aerodynamic data in an aerodynamic coordinate system. The following paragraphs outline the determination to known coordinate systems. + Coordinate systems are a regular cause for ambiguous interpretation of data. + In CPACS, the reference coordinate system is the CPACS-coordinate system. + This coordinate system is used for most of the data. + A single exception is made in order to keep aerodynamic data in an aerodynamic coordinate system. + The following paragraphs outline the determination to known coordinate systems. - The - CPACS - coordinate system is the coordinate system identified by + The CPACS coordinate system is the coordinate system identified by TiGL https://dlr-sc.github.io/tigl - - , - CPACS - 's geometric library. It is a right-handed coordinate system. If an aircraft is defined in the - CPACS - coordinate system it will usually follow the directions listed in the table below. + , CPACS's geometry library. + It is a right-handed coordinate system. If an aircraft is defined in the CPACS coordinate system it will usually follow the directions listed in the table below. - Therefore, the - CPACS - coordinate system can be confused with the body-fixed coordinate system. While often the - CPACS - coordinate system and the body-fixed coordinate system overlap, this must not always be true. Several definitions for body-fixed coordinate systems exist (x-axis through nose and tail, x-axis perpendicular to nose plane). For non-symmetric aircraft, body-fixed coordinate systems become even more complicated. Hence, analysis tools should stick to the - CPACS - -Coordinate system. It remains to the designer to model the geometry accordingly. + Therefore, the CPACS coordinate system can be confused with the body-fixed coordinate system. + While often the CPACS coordinate system and the body-fixed coordinate system overlap, this must not always be true. + Several definitions for body-fixed coordinate systems exist (x-axis through nose and tail, x-axis perpendicular to nose plane). + For non-symmetric aircraft, body-fixed coordinate systems become even more complicated. + Hence, analysis tools should stick to the CPACS coordinate system. + It remains to the designer to model the geometry accordingly. - The - CPACS - coordinate system does not rotate with flow. Hence, aerodynamic calculations do rotate their flow relative to the - CPACS - -coordinate system. If not stated explicitly different, e.g. for target lift-coefficients, results are returned in the - CPACS - coordinate system, i.e. the cfx-coefficient is parallel to the - CPACS - x-Coordinate, regardless of the way the geometry is defined. + The CPACS coordinate system does not rotate with flow. + Hence, aerodynamic calculations do rotate their flow relative to the CPACS coordinate system. + If not stated explicitly different, e.g. for target lift-coefficients, results are returned in the CPACS coordinate system, i.e. the cfx-coefficient is parallel to the CPACS x-coordinate, regardless of the way the geometry is defined. - The following table gives a "best-practice" advice on how to locate a geometry within - CPACS - . Different approaches are, of course, valid as well. + The following table gives a "best-practice" advice on how to locate a geometry within CPACS. + Different approaches are, of course, valid as well. @@ -236,157 +190,96 @@ cpacs@dlr.de - The following figures show an example of a geometry that is aligned with the - CPACS - coordinate system, i.e. the body-fixed coordinate system corresponds to the - CPACS - coordinate system. + The following figures show an example of a geometry that is aligned with the CPACS coordinate system, i.e. the body-fixed coordinate system corresponds to the CPACS coordinate system. - The aerodynamic analysis is relative to the - CPACS - coordinate system. That is, the angle of attack is represented by the dashed orange line. Results of the aerodynamic calculation are given in the - CPACS - coordinate system. + The aerodynamic analysis is relative to the CPACS coordinate system. + That is, the angle of attack is represented by the dashed orange line. + Results of the aerodynamic calculation are given in the CPACS coordinate system. - The following figures give an example of a geometry that is not defined in alignment with the - CPACS - coordinate system. It is a valid - CPACS - file, but only used in this example for demonstrative purposes. + The following figures give an example of a geometry that is not defined in alignment with the CPACS coordinate system. + It is a valid CPACS file, but only used in this example for demonstrative purposes. - The body axes and the - CPACS - coordinate system do not align. That is, the origin of the geometry is not at - CPACS - (0,0,0) but at a point in positive x- and z-direction. + The body axes and the CPACS coordinate system do not align. + That is, the origin of the geometry is not at CPACS (0,0,0) but at a point in positive x- and z-direction. - Again, the aerodynamic analysis is relative to the - CPACS - coordinate system. That is, the angle of attack is represented by the dashed orange line. Results of the aerodynamic calculation are given in the - CPACS - coordinate system. + Again, the aerodynamic analysis is relative to the CPACS coordinate system. + That is, the angle of attack is represented by the dashed orange line. + Results of the aerodynamic calculation are given in the CPACS coordinate system. 3.2. Local coordinate systems via parentUID and transformation - Some elements in - CPACS - , in particular the geometric components, are described in local coordinates. - The hierarchical data structure allows to define a local coordinate system either with respect to the coordinate system of the parent element or with respect to the global - CPACS - coordinate system. - This is achieved by combining the two elements - parentUID - and - transformation - : + Some elements in CPACS, in particular the geometric components, are described in local coordinates. + The hierarchical data structure allows to define a local coordinate system either with respect to the coordinate system of the parent element or with respect to the global CPACS coordinate system. + This is achieved by combining the two elements <parentUID> and <transformation>: - parentUID - : An individual data hierarchy can be set up using the optional - parentUID - element. - Here it is - - important that exactly one element does not contain the - parentUID - - in order to identify the top element of this user-specific hierarchy. - As soon as the - parentUID - (which refers to the - uID - of the parent element) is set, a local coordinate system of the corresponding node is instantiated. + parentUID: An individual data hierarchy can be set up using the optional <parentUID> element. + Here it is important that exactly one element does not contain the <parentUID> + in order to identify the top element of this user-specific hierarchy. + As soon as the parentUID (which refers to the uID of the parent element) is set, a local coordinate system of the corresponding node is instantiated. - transformation - : This allows the coordinate system to be transformed via - translation - , - rotation - and - scaling - . - As soon as the - parentUID - is set, this transformation refers to the local coordinate system (in the current - CPACS - version this only affects - translation - ). - An attribute - refType - is used to either make this explicit ( - refType="absLocal" - ) or to override this and reference the global CPACS coordinate system instead ( - refType="absGlobal" - ). + transformation: This allows the coordinate system to be transformed via + <translation>, + <rotation> and + <scaling>. + As soon as the <parentUID> is set, this transformation refers to the local coordinate system (in the current CPACS version this only affects <translation>). + An attribute refType is used to either make this explicit (refType="absLocal") or to override this and reference the global CPACS coordinate system instead (refType="absGlobal"). - The following table summarizes the possible combinations of - parentUID - and - transformation - and the resulting coordinate system (local or global): + The following table summarizes the possible combinations of <parentUID> and <transformation> and the resulting coordinate system (local or global): - parentUID - not set + <parentUID> not set - parentUID - set + <parentUID> set - transformation - without - refType + <transformation> without refType global local - transformation - with - refType="absLocal" + <transformation> with refType="absLocal" global local - transformation - with - refType="absGlobal" + <transformation> with refType="absGlobal" global global @@ -394,25 +287,14 @@ cpacs@dlr.de Note: - The combination of - transformation - with - refType="absLocal" - and no - parentUID - is global, because the local coordinate system to which the transformation is referring to via - refType - equals the global coordinate system (see fuselage in the following example). + The combination of <transformation> with refType="absLocal" and no <parentUID> is global, + because the local coordinate system to which the transformation is referring to via refType equals the global coordinate system (see fuselage in the following example). An exemplary use case further illustrates the concept of the coordinate system hierarchy. - The - CPACS - schema shall not specify in advance that a wing is always be part of the fuselage and engines must always be part of the wing. + The CPACS schema shall not specify in advance that a wing is always be part of the fuselage and engines must always be part of the wing. In other cases the engine could be attached to the fuselage, which would not be possible via a predefined XML tree. - The following figure shows how components of the aircraft are related to each other via the - parentUID - . + The following figure shows how components of the aircraft are related to each other via the <parentUID>. The fairing is a child of the wing and is therefore automatically translated when the wing is translated. Likewise, the horizontal tailplane is a part of the vertical tailplane and is therefore affected by translation of the latter: @@ -425,9 +307,8 @@ cpacs@dlr.de 4. Units - There are no explicit attributes describing units in - CPACS - . The general convention is that all values must be given in the following SI-units: + There are no explicit attributes describing units in CPACS. + The general convention is that all values must be given in the following SI-units: @@ -436,17 +317,13 @@ cpacs@dlr.de - [m - 2 - ] + [m2] Area - [m - 3 - ] + [m3] Volume @@ -483,10 +360,8 @@ cpacs@dlr.de - The only non SI unit used throughout - CPACS - is the angle in degrees [°]. - For the sake of an intuitive use the angles are given in degrees rather than in radian [rad]. + The only non SI unit used throughout CPACS is the angle in degrees [°]. + For the sake of an intuitive use the angles are given in degrees rather than in radian [rad]. @@ -498,21 +373,14 @@ cpacs@dlr.de - 5. Splitting up a - CPACS - dataset into several files + 5. Splitting up a CPACS dataset into several files - To provide a better overview, it is possible to split up a - CPACS - dataset into several files. This can be done by inserting an - <externaldata> - node at an arbitrary position into the dataset. This node contains a - <path> - node with a URI to the external file(s), followed by one or more - <filename> - nodes, containing each a name of a file to be included at that position. Below, an example of such external data is given: + To provide a better overview, it is possible to split up a CPACS dataset into several files. + This can be done by inserting an <externaldata> node at an arbitrary position into the dataset. + This node contains a <path> node with a URI to the external file(s), followed by one or more <filename> nodes, containing each a name of a file to be included at that position. + Below, an example of such external data is given: - The file would be included completely, except for its title line - <?xml version="1.0" encoding="utf-8"?> - . This concept can also be used recursively (external files of external files), but it is important to prevent circle connections (file "A" loading file "B" loading file "C" loading again file "A" ...). + The file would be included completely, except for its title line <?xml version="1.0" encoding="utf-8"?>. + This concept can also be used recursively (external files of external files), but it is important to prevent circle connections (file "A" loading file "B" loading file "C" loading again file "A" ...). For path URI addresses, the trailing file separator "/" may be omitted. Below, some examples for path URIs are given: Absolute local path: - file:///tmp - or - file:///c:/windows/tmp + file:///tmp or file:///c:/windows/tmp Relative local directory: - file://relativeDirectory - or - file://../anotherRelativeDirectory + file://relativeDirectory or file://../anotherRelativeDirectory Remote net resource: @@ -573,52 +436,34 @@ cpacs@dlr.de - With the help of the - Ti - XI - X - ML - I - nterface + With the help of the TiXI XML Interface TiXI https://github.com/DLR-SC/tixi - - , a - CPACS - dataset that is split into multiple files can be reassembled into a single tree structure for subsequent validation against the - CPACS - schema. The following commands are used to link external data sets: + , a CPACS dataset that is split into multiple files can be reassembled into a single tree structure for subsequent validation against the CPACS schema. + The following commands are used to link external data sets: - <externalFileName> - : Name of the external data file + externalFileName: + Name of the external data file - <externalDataDirectory> - : Directory of the external data file. Its content is analogous to the - externaldata - 's - path - -element described above. + externalDataDirectory: + Directory of the external data file. Its content is analogous to the <externaldata/path> element described above. - <externalDataNodePath> - : + externalDataNodePath: XPath https://www.w3schools.com/xml/xpath_intro.asp - of the node which is replaced with the content of the external file. In case that it is an external file of an external file, then it is the - XPath - in the outer external file. If, e.g., in the example above the - pointList - element would have also been loaded from an external file, then the entry would just be: - externalDataNodePath="/airfoil" - . This is used primarily for loop-detection. + of the node which is replaced with the content of the external file. + In case that it is an external file of an external file, then it is the XPath in the outer external file. + If, e.g., in the example above the <pointList> element would have also been loaded from an external file, then the entry would just be:externalDataNodePath="/airfoil". + This is used primarily for loop-detection. The merged data tree for the example above would look like: @@ -651,22 +496,11 @@ cpacs@dlr.de 6. UIDs and references - The - CPACS - -dataset often uses references between nodes. Typically, these - references define connections between elements which are located somewhere else in the hierarchical dataset (e.g. a - wing - is connected to a - fuselage - ; a specific - engine - is connected to a - pylon - ; etc.). These connections are defined by - unique identifiers - (uID) which are specified as attributes. Thus, there are elements which can be referenced via a - uID - attribute, e.g. a fuselage: + The CPACS-dataset often uses references between nodes. + Typically, these references define connections between elements which are located somewhere else in the hierarchical dataset (e.g. a <wing> is connected to a <fuselage>; + a specific <engine> is connected to a <pylon>; etc.). + These connections are defined by unique identifiers (uID) which are specified as attributes. + Thus, there are elements which can be referenced via a uID attribute, e.g. a fuselage: ... @@ -685,18 +519,13 @@ cpacs@dlr.de - In previous - CPACS - versions, referencing elements were identified via the - isLink="True" - attribute. Since this is superfluous due to the explicit definition of the element properties via the - CPACS - schema, this attribute no longer needs to be listed. It is nevertheless a valid optional attribute to ensure compatibility with older datasets, but might be removed in future versions. + In previous CPACS versions, referencing elements were identified via the isLink="True" attribute. + Since this is superfluous due to the explicit definition of the element properties via the CPACS schema, this attribute no longer needs to be listed. + It is nevertheless a valid optional attribute to ensure compatibility with older datasets, but might be removed in future versions. - Since - uID - s are only used to link nodes within the XML file, no naming convention is required. The characters only have to conform to the conventions of the + Since uIDs are only used to link nodes within the XML file, no naming convention is required. + The characters only have to conform to the conventions of the xsd:ID http://books.xmlschemata.org/relaxng/ch19-77151.html @@ -705,110 +534,47 @@ cpacs@dlr.de W3C https://www.w3.org/ - - . + . UIDs, however, must be unique! - Although a common practice for naming - uID - s is their position in the data hierarchy (e.g. - uID="mainWingSection3" - ), - uID - s as shown in the above example are absolutely valid as well. It is therefore recommended to use the - name - element - to convey human-readable meanings. + Although a common practice for naming uIDs is their position in the data hierarchy (e.g. uID="mainWingSection3"), uIDs as shown in the above example are absolutely valid as well. + It is therefore recommended to use the name element to convey human-readable meanings. - 7. Usage of - name - , - description - and - uID + 7. Usage of name, description and uID CPACS is designed to serve as a central data exchange format in fully automated process chains. A key requirement is therefore that tools can automatically read and process an incoming CPACS file. A second requirement is that users can interpret the data set. - To address both requirements, the following usage of the - name - and - description - elements in combination with the - uID - attribute is proposed: + To address both requirements, the following usage of the <name> and <description> elements in combination with the uID attribute is proposed: - name - : A specification of the - name - element is usually mandatory for sequences of elements (e.g., if max occurrence is unbounded - [1..*] - ). - Typical examples are - wings/wing - , - aeroPerformance/aeroMap - or - missions/mission - . - Such elements must be able to be listed by tools, especially for visualization and reporting purposes, where the - name - element serves as a - concise and human-readable - indicator of the actual meaning of the corresponding element in the list (e.g., which - wing - , which - aeroMap - , which - mission - ). - This is usually a single word or a small number of words. + name: A specification of the <name> element is usually mandatory for sequences of elements (e.g., if max occurrence is unbounded [1..*]). + Typical examples are wings/wing, aeroPerformance/aeroMap or missions/mission. + Such elements must be able to be listed by tools, especially for visualization and reporting purposes, where the <name> element serves as a concise and human-readable indicator of the actual meaning of the corresponding element in the list + (e.g., which wing, which aeroMap, which mission). This is usually a single word or a small number of words. - description - : This element is usually optional and is used to add - comprehensive and human-readable - explanations. This is usually at least one explanatory sentence. + description: + The <description> element is usually optional and is used to add comprehensive and human-readable explanations. + This is usually at least one explanatory sentence. - uID - : As described in more detail in Section 6, the - uID - attribute is mainly used for internal referencing of CPACS elements. - Further processing software, e.g. - TiXI - and - TiGL - , also use the - uID - s to improve the robustness of the data query. - Consequently, the - uID - attribute serves as a - machine-readable - indicator and does not claim to be interpretable by human users. - In some practical use cases, the same string is chosen for - uID - and - name - . - However, restrictions on the choice of characters for the - uID - attribute must be considered, for example that no spaces may be used and the - uID - must be unique. + uID: As described in more detail in Section 6, the uID attribute is mainly used for internal referencing of CPACS elements. + Further processing software, e.g. TiXI and TiGL, also use the uIDs to improve the robustness of the data query. + Consequently, the uID attribute serves as a machine-readable indicator and does not claim to be interpretable by human users. + In some practical use cases, the same string is chosen for uID and <name>. + However, restrictions on the choice of characters for the uID attribute must be considered, for example that no spaces may be used and the uID must be unique. @@ -830,9 +596,7 @@ cpacs@dlr.de Sometimes it might be useful to specify a part of the aircraft as symmetric instead of holding all the data twice in nearly identical form in the dataset (e.g. left and right wing are usually identical, except for the sign of the y-coordinate). - Hence, some parts offer the option to set a - symmetry - attribute: + Hence, some parts offer the option to set a symmetry attribute: - x-y-plane - : Symmetry w.r.t. the x-y plane of the - CPACS - coordinate system + x-y-plane: Symmetry w.r.t. the x-y plane of the CPACS coordinate system - x-z-plane - : Symmetry w.r.t. the x-z plane of the - CPACS - coordinate system + x-z-plane: Symmetry w.r.t. the x-z plane of the CPACS coordinate system - y-z-plane - : Symmetry w.r.t. the y-z plane of the - CPACS - coordinate system + y-z-plane: Symmetry w.r.t. the y-z plane of the CPACS coordinate system - inherit - : Symmetry inherited from parent element (default behavior, i.e. also applies if attribute not set) + inherit: Symmetry inherited from parent element (default behavior, i.e. also applies if attribute not set) - none - : Symmetry inheritance from parent element disabled + none: Symmetry inheritance from parent element disabled - Note - : It must be taken from the documentation of the respective element which of these attribute values may be set. + Note: It must be taken from the documentation of the respective element which of these attribute values may be set. - One example of how to apply the - symmetry - attribute is shown in Sec. 3.2. Another simplified example shown below illustrates the combination of different symmetry properties of 4 wings: + One example of how to apply the symmetry attribute is shown in Sec. 3.2. + Another simplified example shown below illustrates the combination of different symmetry properties of 4 wings: - Wing 1 - is mirrored on the x-z plane. + Wing 1 is mirrored on the x-z plane. - Wing 2 - has wing 1 as parent element, but suppresses its symmetry inheritance. + Wing 2 has wing 1 as parent element, but suppresses its symmetry inheritance. - Wing 3 - has wing 2 as parent element and sets a new symmetry at the x-y plane. + Wing 3 has wing 2 as parent element and sets a new symmetry at the x-y plane. - Wing 4 - has wing 3 as parent element and no symmetry attribute specified. Thus, it inherits the symmetry at the x-y plane from wing 3. + Wing 4 has wing 3 as parent element and no symmetry attribute specified. Thus, it inherits the symmetry at the x-y plane from wing 3. - Note - : The corresponding transformations are not shown here. + Note: The corresponding transformations are not shown here. 8.2. Referencing symmetric elements - All nodes (e.g., - parentUID - ) in - CPACS - that refer to a component holding the symmetry attribute (e.g., wing) might also have a - symmetry - attribute to specify how symmetry is propagated through the resulting element hierarchy. + All nodes (e.g., <parentUID>) in CPACS that refer to a component holding the symmetry attribute (e.g., <wing>) might also have a symmetry attribute to specify how symmetry is propagated through the resulting element hierarchy. - The - symmetry - attribute of a referencing element may take three values: - symm - , - def - , - full - : + The symmetry attribute of a referencing element may take three values: + symm, + def, + full: - def: - The element refers to the geometric component that has a - symmetry - attribute and refers only to the defined side of the geometric component. + def: The element refers to the geometric component that has a symmetry attribute and refers only to the defined side of the geometric component. - symm: - The element refers to the geometric component that has a - symmetry - attribute and refers only to the symmetric side of the geometric component. (Similar to the previous _symm solution) + symm: The element refers to the geometric component that has a symmetry attribute and refers only to the symmetric side of the geometric component. (Similar to the previous _symm solution) - full: - The element refers to the geometric component that has a - symmetry - attribute and refers to the complete component. (This is the default behaviour) + full: The element refers to the geometric component that has a symmetry attribute and refers to the complete component. (This is the default behaviour) @@ -965,14 +691,15 @@ cpacs@dlr.de 9. Vectors and arrays - For large data sets (e.g. increments of aerodynamic coefficients due to control surface deflections) it is advantageous - to map them via vectors and arrays instead of using a sequence of nodes for each data value. Therefore vectors and arrays are defined as semicolon-separated lists in - CPACS - . Via the documentation (derived from the XSD) of the corresponding nodes it has to be checked whether it is a vector or an array. + For large data sets (e.g. increments of aerodynamic coefficients due to control surface deflections) it is advantageous to map them via vectors and arrays instead of using a sequence of nodes for each data value. + Therefore vectors and arrays are defined as semicolon-separated lists in CPACS. + Via the documentation (derived from the XSD) of the corresponding nodes it has to be checked whether it is a vector or an array. Vector - The vector is meant as a one-dimensional-array. In such a node, the values are given in a semicolon separated list: + + The vector is meant as a one-dimensional-array. In such a node, the values are given in a semicolon separated list: + 0.;1.5;3.;4.5;6;7.5;9. @@ -1037,27 +764,32 @@ cpacs@dlr.de 10. Control Parameters - Control parameters are abstract parameters, linking a generic value (i.e., the control parameter) to a configurational state of a control device - (e.g., control surface, landing gear, engine settings, ...). - The basic idea is that this control parameter can be used in different CPACS nodes (e.g., aeroMaps), while the relationship between the abstract control parameter and the configurative state of a controllable component is defined in the latter. - Controllable compents can have multiple control functions (referred to as control devices), e.g., extraction and rotation state as well as the braking state of a landing gear. + + Control parameters are abstract parameters, linking a generic value (i.e., the control parameter) to a configurational state of a control device + (e.g., control surface, landing gear, engine settings, ...). + The basic idea is that this control parameter can be used in different CPACS nodes (e.g., aeroMaps), while the relationship between the abstract control parameter and the configurative state of a controllable component is defined in the latter. + Controllable compents can have multiple control functions (referred to as control devices), e.g., extraction and rotation state as well as the braking state of a landing gear. - Control parameters are predominantly used for control surfaces, which is why they are discussed in more detail below as an example. - However, the approach also applies to other components, such as landing gears. - In future the engines and other components will also be controlable via control parameters. + Control parameters are predominantly used for control surfaces, which is why they are discussed in more detail below as an example. + However, the approach also applies to other components, such as landing gears. + In future the engines and other components will also be controlable via control parameters. + + For control surfaces, the translation from the abstract control parameter to its physical state (i.e., deflection = rotation + translation) + is defined in a so-called <path>, which is componsed of a list of <step> elements. + - For control surfaces, the translation from the abstract control parameter to its physical state (i.e., deflection = rotation + translation) - is defined in a so-called <path>, which is componsed of a list of <step> elements. + The control parameter values for each step are arbitrary floating point values. + However, it is strongly recommended to use values between -1 and +1, or between 0 and +1 (depending on the type of control surface). + The smallest and the largest value implicitly define the maximum deflection limits. + It is mandatory, that the value “0” is within the specified range, as this value is treated as undeflected and used to specify a “clean” aircraft configuration (e.g. used in the clean aero performance map). + Furthermore, it it is mandatory for the <step> elements to be sorted in ascending order of the control parameters. + It is recommended, but not mandatory to specify a <step> with a <controlParameter> of 0. + Consequently, no <controlParameter> must be used twice within a single <path> definition. + Deflection values between two specified steps are handled by linear interpolation. - The control parameter values for each step are arbitrary floating point values. However, it is strongly recommended to use - values between -1 and +1, or between 0 and +1 (depending on the type of control surface). The smallest and the largest value implicitly - define the maximum deflection limits. It is mandatory, that the value “0” is within the specified range, as this value is treated as - undeflected and used to specify a “clean” aircraft configuration (e.g. used in the clean aero performance map). - Furthermore, it it is mandatory for the <step> elements to be sorted in ascending order of the control parameters. - It is recommended, but not mandatory to specify a <step> with a <controlParameter> of 0. Consequently, no <controlParameter> must be used twice within - a single <path> definition. Deflection values between two specified steps are handled by linear interpolation. - The following example shows the usage of control parameters within a control surface deflection path definition: + + The following example shows the usage of control parameters within a control surface deflection path definition: @@ -1088,7 +820,7 @@ cpacs@dlr.de ]]> - There is a possibility that more than one deflection command is applied to a control surface at the same time (e.g. coming from a configuration definition and from an explicit deflection). + There is a possibility that more than one deflection command is applied to a control surface at the same time (e.g. coming from a <configurationDefinition> and from an explicit deflection). Furthermore, a control surface could be deflected by one (or even multiple) control distributor and control device command(s) in parallel. In all these cases, the deflection commands have to be superposed in the following way: @@ -1101,10 +833,10 @@ cpacs@dlr.de The control device control parameters for each control device (coming from control distributor and from control device commands) have to be added up. - The final control device control parameters for each control device have to be evaluated considering the paths specification to come to the desired movements/deflections. + The final control device control parameters for each control device have to be evaluated considering the corresponding <path> specification to come to the desired movements/deflections. - If command inputs or control parameters in step 2.) or 4.) are found to exceed the or boundaries of the defined range , an error should be returned from the evaluation. + If command inputs or control parameters in step 2.) or 4.) are found to exceed the or boundaries of the defined range, an error should be returned from the evaluation. @@ -1114,37 +846,29 @@ cpacs@dlr.de 11. Atmosphere - At some places in - CPACS - , an atmosphere has to be selected (e.g. for connecting an altitude with a certain pressure or density). - Currently, - CPACS - does only support a single atmospheric model: The ICAO Standard Atmosphere (ISA) from 1993 (see ICAO Doc 7488/3 'MANUAL OF THE ICAO STANDARD ATMOSPHERE', third edition, 1993) - It covers temperature, pressure, density, speed of sound, dynamic viscosity and kinematic viscosity with respect to altitude. - In - CPACS - , 'altitude' means what is called 'geopotential altitude' (H) in the ISA reference document and is given in [m]. - For details, see ISA manual, section 2.3, page E-viii f. - ISA covers a range from -5000 m to 80000 m. + At some places in CPACS, an atmosphere has to be selected (e.g. for connecting an altitude with a certain pressure or density). + Currently, CPACS does only support a single atmospheric model: The ICAO Standard Atmosphere (ISA) from 1993 (see ICAO Doc 7488/3 'MANUAL OF THE ICAO STANDARD ATMOSPHERE', third edition, 1993). + It covers temperature, pressure, density, speed of sound, dynamic viscosity and kinematic viscosity with respect to altitude. + In CPACS, <altitude> means what is called 'geopotential altitude' (H) in the ISA reference document and is given in [m]. + For details, see ISA manual, section 2.3, page E-viii f. + ISA covers a range from -5000 m to 80000 m. - Temperature offsets are introduced on top of the definitions in the ISA manual (which does not cover such variations). The offset model - is based upon the idea that the pressure at a fixed geopotential altitude is independent from temperature offset (pressure altitude). - The temperature offset changes only the density (following rho = p / Gas Constant / T) (and viscosity, of course) + + Temperature offsets are introduced on top of the definitions in the ISA manual (which does not cover such variations). + The offset model is based upon the idea that the pressure at a fixed geopotential altitude is independent from temperature offset (pressure altitude). + The temperature offset changes only the density (following rho = p / Gas Constant / T) (and viscosity, of course) - CPACS 3.5-RC + CPACS 3.5 Release in November 2023 - new - headerType - and versioning strategy + new headerType and versioning strategy - cpacsVersion - marked as deprecated and moved to versionInfo node + cpacsVersion marked as deprecated and moved to versionInfo node fix typos: @@ -1156,79 +880,56 @@ cpacs@dlr.de mAdditionalCenterTanks - consistency - in - globalBeamPropertiesType + consistency in globalBeamPropertiesType - capType - : add - uID + capType: add uID massBreakdown - genericMassTyp - : add - componentUID - to link the corresponding components + genericMassTyp: add componentUID to link the corresponding components - mOperatorItemsType - : + mOperatorItemsType: - add - mAdditionalCenterTanks + add mAdditionalCenterTanks - add - mEngineAPUOils + add mEngineAPUOils - add - mRemovableCrewRests + add mRemovableCrewRests - add - mToiletFluids + add mToiletFluids - add - mUnusableFuels + add mUnusableFuels - add - mWaterReservoirs + add mWaterReservoirs - add - mMiscellaneous + add mMiscellaneous - align - mLandingGear - elements with more the new generic - landingGears - definition + align mLandingGear elements with more the new generic landingGears definition add mGenericFuelTanks to mFuselageStructure - sparPositionType - : add - sparPositionCurve - (defines a spar position via a point on a curve) + sparPositionType: add sparPositionCurve (defines a spar position via a point on a curve) - isLink - attribute: marked as deprecated + isLink attribute: marked as deprecated Systems definition @@ -1237,9 +938,7 @@ cpacs@dlr.de - configurationUID - , ... --> - configurationDefinitionUID + configurationUID, ... --> configurationDefinitionUID @@ -1249,8 +948,7 @@ cpacs@dlr.de - add - systemAnalyses + add systemAnalyses @@ -1260,12 +958,10 @@ cpacs@dlr.de - add - configurationDefinitions + add configurationDefinitions - add - systemArchitectures + add systemArchitectures @@ -1275,27 +971,20 @@ cpacs@dlr.de - add - rotors + add rotors - fuels - replaced by - chemicalEnergyCarriers - and - electricalEnergyCarriers + fuels replaced by chemicalEnergyCarriers and electricalEnergyCarriers make sub-elements optional - genericSystemType - : add - components + genericSystemType: add components @@ -1303,12 +992,10 @@ cpacs@dlr.de - add - configurations + add configurations - mPayload - optional + mPayload optional @@ -1318,16 +1005,13 @@ cpacs@dlr.de - add - systemElements + add systemElements - add - rotorElements + add rotorElements - add - energyCarriers + add energyCarriers @@ -1337,8 +1021,7 @@ cpacs@dlr.de - add - configurations + add configurations @@ -1348,40 +1031,28 @@ cpacs@dlr.de - add - systemAnalyses/powerBreakdowns + add systemAnalyses/powerBreakdowns add cryogenic fuel storage - add - ducts - definition + add ducts definition hinge line definition aligned with TiGL - fix wront type assignment in - costHydraulicSystemsType + fix wront type assignment in costHydraulicSystemsType - wingWingAttachmentType - : - upperShellAttachment - and - lowerShellAttachment - restricted to - upperShell - and - lowerShell + wingWingAttachmentType: + upperShellAttachment and lowerShellAttachment restricted to + upperShell and lowerShell - add - wingCutouts + add wingCutouts - add - fuselageStructuralMountsType + add fuselageStructuralMountsType controlSurfaceTrackTypeType: joint position names in figures changed to count from P1 @@ -1397,101 +1068,43 @@ cpacs@dlr.de Release in April 2022 - Revision of - decks - definition ( - compatibility break - ) + Revision of decks definition (compatibility break) - Mass breakdown: add - mSparSkins - and - mSparCells - to - mSpar + Mass breakdown: add mSparSkins and mSparCells to mSpar - Mass breakdown: fix hierarchical error in - mMiscellaneous - ( - compatibility break - ) + Mass breakdown: fix hierarchical error in mMiscellaneous (compatibility break) - Mass breakdown: fix typo in - mPylon - ( - compatibility break - ) + Mass breakdown: fix typo in mPylon (compatibility break) - Nacelle guide curves: set - description - optional + Nacelle guide curves: set description optional - Mission definition: add - uID - to elements in - geographicPointConstraintType + Mission definition: add uID to elements in geographicPointConstraintType - Mission definition: add - powerFraction - , - powerRemaining - and - powerConsumed - to - missionSegmentEndConditionType + Mission definition: add powerFraction, + powerRemaining and powerConsumed to missionSegmentEndConditionType - Mission definition: rename - referenceEndCondition - to - referenceEndConditionUID - in - constraintSettingsType - ( - compatibility break - ) + Mission definition: rename referenceEndCondition to referenceEndConditionUID in constraintSettingsType (compatibility break) - Mission definition: rename - reqClassification - to - requirementClassification - in - flightPerformanceRequirementType - ( - compatibility break - ) + Mission definition: rename reqClassification to requirementClassification in flightPerformanceRequirementType (compatibility break) Add contour coordinates for cell definition Add vehicle independent node for external geometry - Remove - paxFlow - element from - aircraftAnalysesType - ( - compatibility break - ) + Remove paxFlow element from aircraftAnalysesType (compatibility break) - Docs: improve documentation of - name - , - description - and - uID - usage + Docs: improve documentation of name, description and uID usage - Docs: add description of - parentUID - concept + Docs: add description of parentUID concept Docs: add description of symmetry inheritance Docs: add description of engine nacelles @@ -1506,54 +1119,34 @@ cpacs@dlr.de Release in June 2021 - Revision of the mission definition including parameter lapses within segments ( - compatibility break - ) + Revision of the mission definition including parameter lapses within segments (compatibility break) - Revision of the point performance definition ( - compatibility break - ) + Revision of the point performance definition (compatibility break) - Revision of performance requirements ( - compatibility break - ) + Revision of performance requirements (compatibility break) - Revision of landing gears ( - compatibility break - ) + Revision of landing gears (compatibility break) - Revision of control surface tracks definition ( - compatibility break - ) + Revision of control surface tracks definition (compatibility break) - Load analysis: Revision of flightLoadCasesType ( - compatibility break - ) + Load analysis: Revision of flightLoadCasesType (compatibility break) - Load analysis: Revision of aeroCasesType ( - compatibility break - ) + Load analysis: Revision of aeroCasesType (compatibility break) - Load analysis: loadEnvelopesType relocated and envelope simplified to a single uID-Sequence ( - compatibility break - ) + Load analysis: loadEnvelopesType relocated and envelope simplified to a single uID-Sequence (compatibility break) - Load analysis: Replaced dynamicAircraftModel elements by loadApplicationPointSets ( - compatibility break - ) + Load analysis: Replaced dynamicAircraftModel elements by loadApplicationPointSets (compatibility break) - Flight dynamics: Group flightPerformance, flyingQualities and trim under flightDynamics parent node ( - compatibility break - ) + Flight dynamics: Group flightPerformance, flyingQualities and trim under flightDynamics parent node (compatibility break) Introduced a configuration node to describe aircraft and payload configurations Fuselage profiles: Introduced rectangle and super ellipse as standard profiles @@ -1570,24 +1163,16 @@ cpacs@dlr.de Added 'none' and 'inherit' to list of symmetry flags Set mapType attribute of vector and array elements to optional (requires TiXI>=3.1) - AeroMaps: Defined angleOfSideslip as input and added distinction between minimum and maximum angleOfAttack in aeroLimitMaps ( - compatibility break - ) + AeroMaps: Defined angleOfSideslip as input and added distinction between minimum and maximum angleOfAttack in aeroLimitMaps (compatibility break) - AeroMaps: Added missing singular incrementMap element to incrementMaps in aeroLimitsMap ( - compatibility break - ) + AeroMaps: Added missing singular incrementMap element to incrementMaps in aeroLimitsMap (compatibility break) - AeroMaps: Adopted the camelCase style for damping derivatives ( - compatibility break - ) + AeroMaps: Adopted the camelCase style for damping derivatives (compatibility break) - Introduced common nomenclature for speeds and altitudes ( - compatibility break - ) + Introduced common nomenclature for speeds and altitudes (compatibility break) Control distributors are set to optional Added instructions for superposition of control surface deflections @@ -2628,53 +2213,20 @@ cpacs@dlr.de This map explicitly specifies limitations of a vehicle in terms of angles of attack and sideslip angles. - All vectors, i.e. - altitude - , - machNumber - , - angleOfSideslip - and - angleOfAttack - , must have the - same length. To avoid redundancy with the - aeroPerformanceMap - , this type does not contain - any aerodynamic coefficients. + All vectors, i.e. altitude, machNumber, angleOfSideslip and angleOfAttack, + must have the same length. To avoid redundancy with the aeroPerformanceMap, this type does not contain any aerodynamic coefficients. + + + Since angleOfSideslip and angleOfAttack are closely interdependent for a given machNumber and altitude combination, + a positive and negative maximum angleOfAttack is defined for a given combination of machNumber, altitude and angleOfSideslip. + The limits of angleOfSideslip can be determined by evaluating the nominal decrease of angleOfAttack values + or by agreeint with the data supplier that the minimum and maximum value of the angleOfSideslip vector corresponds with physical limits. - Since - angleOfSideslip - and - angleOfAttack - are closely interdependent for a given - machNumber - and - altitude - combination, a positive and negative maximum - angleOfAttack - is defined for a given combination of - machNumber - , - altitude - and - angleOfSideslip - . The limits of - angleOfSideslip - can be determined by evaluating the nominal decrease of - angleOfAttack - values or by - agreeint with the data supplier that the minimum and maximum value of the - angleOfSideslip - vector corresponds with physical limits. + In order to avoid data redundancy, the operational limits should not reflect the extrema of aerodynamic coefficients as these can be extracted from the performanceMap via interpolation. - In order to avoid data redundancy, the operational limits should not reflect the extrema of aerodynamic - coefficients as these can be extracted from the performanceMap via interpolation. - Note: - In future CPACS versions, a revision of the - aeroLimitsMap - will be targeted, since operational limits are not a purely aerodynamic issue. + Note: In future CPACS versions, a revision of the aeroLimitsMap will be targeted, since operational limits are not a purely aerodynamic issue. @@ -3053,18 +2605,9 @@ cpacs@dlr.de Description - The aeroPerformanceMap contains a map - with aerodynamic data of the complete aircraft in the form of - nondimensional coefficients. The force coefficients in - i - -direction ( - ci - ) - are nondimensionalized by dynamic pressure and reference area, - the moment coefficients ( - cmi - ) by dynamic pressure, reference - area and reference length. + The aeroPerformanceMap contains a map with aerodynamic data of the complete aircraft in the form of nondimensional coefficients. + The force coefficients in i-direction (ci) are nondimensionalized by dynamic pressure and reference area, + the moment coefficients (cmi) by dynamic pressure, reference area and reference length. All coefficients in the aeroPerformanceMap relate to the aerodynamic coordinate system which is deducted from the CPACS coordinate system by @@ -3073,20 +2616,11 @@ cpacs@dlr.de The dependent parameters of the aeroPerformanceMap are - altitude - , - machNumber - , - angleOfSideslip - and - angleOfAttack - . These elements are vectors of equal length, where values - with identical indices belong together. The solution vectors - ci - and - cmi - have the same length as the input vectors. Shown below is an example where - with 10 values per vector: + altitude, + machNumber, + angleOfSideslip and + angleOfAttack. + These elements are vectors of equal length, where values with identical indices belong together. The solution vectors ci and cmi have the same length as the input vectors. Shown below is an example where with 10 values per vector: <altitude mapType="vector">12e+02;12e+02;12e+02;12e+02;12e+02;12e+02;12e+02;12e+02;12e+02;12e+02</altitude> <machNumber mapType="vector">0.2;0.2;0.2;0.2;0.2;0.2;0.2;0.2;0.2;0.2</machNumber> @@ -3098,20 +2632,11 @@ cpacs@dlr.de The aerodynamic coefficients for - altitude - =1200m, - machNumber - =0.2, - angleOfSideslip - =0° and - angleOfAttack - =6° can be found at the 5th index: - cd - =0.208, - cs - =0 and - cl - =0.46. + altitude=1200m, + machNumber=0.2, + angleOfSideslip=0° and + angleOfAttack=6° can be found at the 5th index: + cd=0.208, cs=0 and cl=0.46. @@ -3154,25 +2679,21 @@ cpacs@dlr.de - Drag coefficient in aerodynamic - coordinates + Drag coefficient in aerodynamic coordinates - Coefficient of the side force vector in - aerodynamic coordinates (perpendicular - to lift and drag) + Coefficient of the side force vector in aerodynamic coordinates (perpendicular to lift and drag) - Lift coefficient in aerodynamic - coordinates + Lift coefficient in aerodynamic coordinates @@ -3440,43 +2961,19 @@ cpacs@dlr.de - The - aircraftModelType - contains the geometric aircraft - model and associated data. + The aircraftModelType contains the geometric aircraft model and associated data. - Elements specifying the geometry of the aircraft are - fuselages - , - wings - , - engines - (referenced via - uID - ), - enginePylons - , - landingGear - , - systems - (to some extend) and - genericGeometryComponents - . + Elements specifying the geometry of the aircraft are fuselages, wings, engines (referenced via uID), + enginePylons, landingGear, systems (to some extend) and genericGeometryComponents. - Other elements are dedicated to additional data associated to this aircraft model. Brief and concise analysis results are stored - in the - global - node. The - analysis - node contains - extensive results from multidisciplinary analysis modules. + Other elements are dedicated to additional data associated to this aircraft model. + Brief and concise analysis results are stored in the global node. + The analysis node contains extensive results from multidisciplinary analysis modules. - In the current CPACS version requirements only refer to the aircraft performance and are therefore specified in the - performanceRequirements - node. + In the current CPACS version requirements only refer to the aircraft performance and are therefore specified in the performanceRequirements node. @@ -3528,16 +3025,10 @@ cpacs@dlr.de - The - aircraftType - contains a list of aircraft models. + The aircraftType contains a list of aircraft models. - Note: Since there is no distinction between plural and singular in English, - aircraft - refers to plural form, while a single aircraft itself is referenced as - model - . + Note: Since there is no distinction between plural and singular in English, aircraft refers to plural form, while a single aircraft itself is referenced as model. @@ -5269,23 +4760,13 @@ cpacs@dlr.de - [ - WARNING: - This type is known to be susceptible to - inconsistencies and might therefore be removed in a future version of CPACS] + [WARNING: This type is known to be susceptible to inconsistencies and might therefore be removed in a future version of CPACS] The geometry of the cabin roughly corresponds to the available design space in the cabin. It is given in terms of constant height contour lines. - The lines all share a common - x - -vector. - The - y - vector provides the lateral - contour at Z-coordinate provided by the constant value - z - . + The lines all share a common x-vector. + The y vector provides the lateral contour at z-coordinate provided by the constant value z. One or more contour lines can be given. The cabin geometry is assumed to be symmetric. @@ -6272,44 +5753,14 @@ cpacs@dlr.de Describes the contributions of a specific par within a wing segment to the total aerodynamic coefficients of a wing segment strip - A - chordwisePart - aescribes the contributions of a specific chordwise part within a wing - strip - to the total aerodynamic coefficients of this - strip - . It extends spatially between the two - eta - positions of the parent - strip - (see - strip - documentation) and four - xsi - positions in the segment coordinate system. - As with the parent stips, only the trailing border ( - ..ToSegmentXsi - ) of a - chordwisePart - is defined, while the leading border always equals the trailing border of the preceding - chordwisePart - (or - 0 - for the first part). - To account for oblique trailing borders (e.g., to match the aileron on a tapered wing) two different - toSegmentXsi - positions can be defined, one at the inner border ( - innerBorderToSegmentXsi - ) and one at the outer border ( - innerBorderToSegmentXsi - ) of the parent strip. - The - innerBorderToSegmentXsi - and - outerBorderToSegmentXsi - of the last - chordwisePart - must be equal to 1. + A chordwisePart describes the contributions of a specific chordwise part within a wing strip to the total aerodynamic coefficients of this strip. + It extends spatially between the two eta positions of the parent strip (see strip documentation) + and four xsi positions in the segment coordinate system. + As with the parent stips, only the trailing border (..ToSegmentXsi) of a chordwisePart is defined, + while the leading border always equals the trailing border of the preceding chordwisePart (or 0 for the first part). + To account for oblique trailing borders (e.g., to match the aileron on a tapered wing) two different toSegmentXsi positions can be defined, + one at the inner border (innerBorderToSegmentXsi) and one at the outer border (innerBorderToSegmentXsi) of the parent strip. + The innerBorderToSegmentXsi and outerBorderToSegmentXsi of the last chordwisePart must be equal to 1. @@ -6576,17 +6027,9 @@ cpacs@dlr.de Describes the contributions of a specific wing segment to the total aerodynamic coefficients of a wing - It is obligatory to reference a segment via its - uID - and to provide its - coefficients - . The breakdown of the coefficients comprises the - strips - and - remainingContributions - . The latter must only be specified if - strips - is given. + It is obligatory to reference a segment via its uID and to provide its coefficients. + The breakdown of the coefficients comprises the strips and remainingContributions. + The latter must only be specified if strips is given. @@ -6647,54 +6090,22 @@ cpacs@dlr.de - Describes the contributions of a specific strip within a wing segment to the total aerodynamic coefficients of a wing segment - + Describes the contributions of a specific strip within a wing segment to the total aerodynamic coefficients of a wing segment + - The strip extends spatially between two - eta - coordinates (i.e., - from - an inner border - to - an outer border). - In order to avoid redundancy, the inner border (denoted as - from - ) is always identical to the outer border of the previous strip (denoted by - to - ). - Accordingly, only the - to - -border can be specified explicitly, while the - from - -border equals implicitly either to - 0 - (for the first strip) or the - toSegmentEta - value of the previous element. The - toSegmentEta - of the last - strip - must be equal to 1! + The strip extends spatially between two eta coordinates (i.e., from an inner border to an outer border). + In order to avoid redundancy, the inner border (denoted as from) is always identical to the outer border of the previous strip (denoted by to). + Accordingly, only the to-border can be specified explicitly, + while the from-border equals implicitly either to 0 (for the first strip) or the toSegmentEta value of the previous element. + The toSegmentEta of the last strip must be equal to 1! - It is obligatory to provide the - coefficients - of the - strip - . The breakdown comprises the - chordwiseParts - and - remainingContributions - . The latter must only be specified if the breakdown into - chordwiseParts - is given. This breakdown is optional. If it is specified, but the sum of all chordwiseParts does not match the strip coefficients, one or more - remainingContributions - may be applied - to ensure consistency (sum of all - chordwiseParts - + sum of all - remainingContributions - must be equal to total strip coefficients). + It is obligatory to provide the coefficients of the strip. + The breakdown comprises the chordwiseParts and remainingContributions. + The latter must only be specified if the breakdown into chordwiseParts is given. + This breakdown is optional. + If it is specified, but the sum of all chordwiseParts does not match the strip coefficients, one or more remainingContributions may be applied to + ensure consistency (sum of all chordwiseParts + sum of all remainingContributions must be equal to total strip coefficients). @@ -6732,28 +6143,14 @@ cpacs@dlr.de - Breakdown of the total aerodynamic coefficients into contributions - from the various vehicle componenents. A detailed breakdown is only specified - for the wing. Other components, such as the fuselage, are more generically - referred to as - otherComponents - . Since - the sum of the contributions within a breakdown must equal the total - coefficients, the remaining contributions must be listed in - remainingContributions - . + Breakdown of the total aerodynamic coefficients into contributions from the various vehicle componenents. + A detailed breakdown is only specified for the wing. + Other components, such as the fuselage, are more generically referred to as otherComponents. + Since the sum of the contributions within a breakdown must equal the total coefficients, the remaining contributions must be listed in remainingContributions. - The - remainingContributions - cannot be defined alone. Either the - definition of a - wing - , - otherComponents - or both together is valid and can be combined with - remainingContributions - . + The remainingContributions cannot be defined alone. + Either the definition of a wing, otherComponents or both together is valid and can be combined with remainingContributions. @@ -6838,17 +6235,9 @@ cpacs@dlr.de Describes the contributions of a specific wing to the total aerodynamic coefficients of a vehicle - It is obligatory to reference a wing via its - uID - and to provide its - coefficients - . The breakdown of the coefficients comprises the - segments - and - remainingContributions - . The latter must only be specified if - segments - is given. + It is obligatory to reference a wing via its uID and to provide its coefficients. + The breakdown of the coefficients comprises the segments and remainingContributions. + The latter must only be specified if segments is given. @@ -7755,9 +7144,9 @@ cpacs@dlr.de Specification of performance constraints. - Constraints allow vectors of double values to define parameter lapses within a mission segment. The example below illustrates this by means of an exemplary climb profile of a conventional airliner, in which multiple physical and regulatory speed constraints are simultaneously specified over several altitudes (e.g., to account for the - crossover altitude - ): + Constraints allow vectors of double values to define parameter lapses within a mission segment. + The example below illustrates this by means of an exemplary climb profile of a conventional airliner, in which multiple physical and regulatory speed constraints are simultaneously specified over several altitudes + (e.g., to account for the crossover altitude): <endCondition> <positionGeo> @@ -8045,66 +7434,28 @@ cpacs@dlr.de single controlDistributor bundling several controlElements - Within some analyses, it might occur that overlapping control element settings are specified. In this case, - it is assumed that a cumulative setting is built by summing up the individual settings. As the behavior of these settings - is not necessarily linear, a certain order of summation has to be followed: + Within some analyses, it might occur that overlapping control element settings are specified. + In this case, it is assumed that a cumulative setting is built by summing up the individual settings. + As the behavior of these settings is not necessarily linear, a certain order of summation has to be followed: - The command inputs for each - controlDistributor - , coming from the - configurationUID - , as well as from separate settings have to be summed up to a total - commandInput - . + The command inputs for each controlDistributor, coming from the configurationUID, as well as from separate settings have to be summed up to a total commandInput. - With this total - commandInput - , each corresponding - controlDistributor - definition has to be evaluated, in order to get - controlParameter - settings for a number of - controlDevices - . + With this total commandInput, each corresponding controlDistributor definition has to be evaluated, + in order to get controlParameter settings for a number of controlDevices. - All - controlParameter - settings for a - controlDevice - , coming from the - configurationUID - , from the - controlDistributors - and from separate - controlDevice - settings have to be summed up to get a total - controlParameter - for each controlDevice. + All controlParameter settings for a controlDevice, coming from the configurationUID , + from the controlDistributors and from separate controlDevice settings have to be summed up to get a total controlParameter for each controlDevice. - With this total - controlParameter - , each corresponding - controlDevice - definition has to be evaluated, in order to find out what the control device finally is doing. + With this total controlParameter, each corresponding controlDevice definition has to be evaluated, in order to find out what the control device finally is doing. - During the summation process (depending on the order of processing within step 1 to 4), - commandInputs - or - controlParameters - might exceed the specified limits for that - controlDistributor - or - controlDevices - . As an intermediate result, this should be accepted – however, when it comes to evaluation in step 2 and 4, all - commandInputs - and - controlParameters - have to be within the specified limits. + During the summation process (depending on the order of processing within step 1 to 4), commandInputs or controlParameters might exceed the specified limits for + that controlDistributor or controlDevices. + As an intermediate result, this should be accepted – however, when it comes to evaluation in step 2 and 4, all commandInputs and controlParameters have to be within the specified limits. @@ -9113,7 +8464,7 @@ cpacs@dlr.de the right hand rule. The rotation of the control surface is defined as rotation around the positive y-hinge line. - The deflection of the control surface is defined by at + The deflection of the control surface is defined by at least two steps. It is specified as follows: First the x-deflection at the inner and outer border; afterwards the z-deflection of the inner and outer border; last the @@ -9363,7 +8714,7 @@ cpacs@dlr.de the right hand rule. The rotation of the control surface is defined as rotation around the positive y-hinge line. - The deflection of the control surface is defined by at + The deflection of the control surface is defined by at least two steps. It is specified as follows: First the x-deflection at the inner and outer border; afterwards the z-deflection of the inner and outer border; last the @@ -9473,46 +8824,27 @@ cpacs@dlr.de - Control surface tracks (mechnaical link between control - surface and parent). + Control surface tracks (mechnaical link between control surface and parent). - A - track - generally describes the structural connection between a control surface and a wing (or parent element). For example, a track can be a flap track, a revolute joint connecting an aileron or spoiler, or the kinematics of slats on a wing. + A track generally describes the structural connection between a control surface and a wing (or parent element). + For example, a track can be a flap track, a revolute joint connecting an aileron or spoiler, or the kinematics of slats on a wing. - The spanwise position of the track is defined by - etaPosition - , which refers to the control surface dimensions. + The spanwise position of the track is defined by etaPosition, which refers to the control surface dimensions. - The structural properties of the track (e.g. - materials) are defined in - trackStructure - . + The structural properties of the track (e.g. materials) are defined in trackStructure. - If an actuator is included into the the track, a - reference is given in - actuator - . + If an actuator is included into the the track, a reference is given in actuator. - The principal kinematic of the track is defined by - setting the - trackType - and - trackSubType - . Please refer to the - tables below for setting the - trackType - and - trackSubType - parameter. Note, those tables are not final - they are extended - continuously. + The principal kinematic of the track is defined by setting the trackType and trackSubType. + Please refer to the tables below for setting the trackType and trackSubType parameter. + Note, those tables are not final - they are extended continuously. @@ -12556,7 +11888,7 @@ cpacs@dlr.de In - CPACS + CPACS arrays are used to exchange values in full-factorial parameter spaces, for example to describe the aerodynamic coefficients depending on Mach number and altitude. @@ -12593,7 +11925,7 @@ cpacs@dlr.de Please note that the syntax of arrays in the current - CPACS + CPACS version correspond exactly to the syntax of vectors. There is no special character indicating the dimensions. Thus, the input vectors have to be determined from the documentation of the corresponding elements and splitting of the one-dimensional vector has to be done manually. @@ -17670,36 +17002,29 @@ The fuel tank volume type should also be used for the wing fuel tank - parentUID - not set + parentUID not set - parentUID - set + parentUID set - location - without - refType + location without refType global local - location - with - refType="absLocal" + location with refType="absLocal" global local - location - with + location with refType="absGlobal" global @@ -17707,18 +17032,8 @@ The fuel tank volume type should also be used for the wing fuel tank - Note: - The combination of - location - with - refType="absLocal" - and no - parentUID - is global, because the local coordinate system to which the - location - is referring to via - refType - equals the global coordinate system. + Note: The combination of location with refType="absLocal" and no parentUID is global, + because the local coordinate system to which the location is referring to via refType equals the global coordinate system. Specification of performance cases required for the performance evaluation of air vehicles (aircraft, rotorcraft, etc.). - The information in this node is - generally - applicable to any kind of vehicle. - Vehicle-specific - information is provided through the performanceRequirements node found under: - /cpacs/vehicles/../model/performanceCases - . + The information in this node is generally applicable to any kind of vehicle. + Vehicle-specific information is provided through the performanceRequirements node found under: + /cpacs/vehicles/../model/performanceCases. @@ -20660,28 +19971,19 @@ The fuel tank volume type should also be used for the wing fuel tank - Reference a wing, fuselage or control surface by its - uID - using the - componentUID - node. + Reference a wing, fuselage or control surface by its uID using the componentUID node. - Define a reference axis through the above component with the - loadReferenceLine - element to specify where a load distribution shall be applied. + Define a reference axis through the above component with the loadReferenceLine element to specify where a load distribution shall be applied. - Compute the intersections with (e.g.) ribs of the referenced component (wing, fuselage or control surface) and write the results into - loadApplicationPoints - . This procedure results from common practice where the forces in structural analyses are typically introduced at structural elements such as ribs and spars. With respect to preliminary aircraft design a two-dimensional load distribution is preferred. However, an arbitrary distribution of the load application points is possible (without the intersection of structural elements with a reference axis in the previous step), for example to define discrete load distributions on the wing surface in streamwise and spanwise direction. + Compute the intersections with (e.g.) ribs of the referenced component (wing, fuselage or control surface) and write the results into loadApplicationPoints. + This procedure results from common practice where the forces in structural analyses are typically introduced at structural elements such as ribs and spars. + With respect to preliminary aircraft design a two-dimensional load distribution is preferred. + However, an arbitrary distribution of the load application points is possible (without the intersection of structural elements with a reference axis in the previous step), for example to define discrete load distributions on the wing surface in streamwise and spanwise direction. - Specify the location and orientation of cut loads in the - cutLoadIntegrationPoints - element and the corresponding connectivity information in the - connectivities - node. + Specify the location and orientation of cut loads in the cutLoadIntegrationPoints element and the corresponding connectivity information in the connectivities node. @@ -21777,28 +21079,16 @@ The fuel tank volume type should also be used for the wing fuel tank1. General - The - massBreakeDown - is subdivided in - designMasses - , - fuel - , - payload - and - mOME - (operating empty mass). + The massBreakeDown is subdivided in designMasses, + fuel, payload and mOME (operating empty mass). designMass - The design masses contain the overall values for - mTOM and so forth. These should be listed as specified by the - TLAR or found from initial sizing. + The design masses contain the overall values for mTOM and so forth. + These should be listed as specified by the TLAR or found from initial sizing. - fuel - and - payload + fuel and payload The fuel and payload nodes should contain maximum values, i.e. full fuel tanks, all passengers on board and full @@ -21810,10 +21100,8 @@ The fuel tank volume type should also be used for the wing fuel tankmOEM - The operation empty mass structure is based on the Airbus Mass - Standard brake down [AIRBUS MASS STANDARD 2008]. The - operator’s mass empty (OME) is defined by the sum of the - following component masses: + The operation empty mass structure is based on the Airbus Mass Standard brake down [AIRBUS MASS STANDARD 2008]. + The operator’s mass empty (OME) is defined by the sum of the following component masses: operator’s items manufacturer’s mass empty (MME) @@ -21826,9 +21114,7 @@ The fuel tank volume type should also be used for the wing fuel tank2. massDescription - Each sub component has the following - massDescription - which include a: + Each sub component has the following massDescription which include a: Name Description @@ -21840,17 +21126,8 @@ The fuel tank volume type should also be used for the wing fuel tank - The - massdescription - can be found at the - designMasses - direct under each item. At the - fuel - , - payload - and - mOME - under massDescription in each item and sub item. + The massdescription can be found at the designMasses direct under each item. + At the fuel, payload and mOME under massDescription in each item and sub item. Concerning symmetry please note that any item referenced by its UID, e.g. wingUID, accounts for the complete @@ -24048,13 +23325,15 @@ The fuel tank volume type should also be used for the wing fuel tank General description - Specifies mission profiles required for the performance evaluation of air vehicles (aircraft, rotorcraft, etc.). The missionDefininitions node is constructed in such a way, that all civil aircraft missions and missions from MIL-STD-3013A can be specified. + Specifies mission profiles required for the performance evaluation of air vehicles (aircraft, rotorcraft, etc.). + The missionDefininitions node is constructed in such a way, that all civil aircraft missions and missions from MIL-STD-3013A can be specified. > Hierarchical buildup of the mission definition - The mission definition is built-up in a hierarchical way. As the topmost element of the hierarchical mission definition, missions are created within the missions node. Here, one or more segmentBlocks are referenced. These again link to a sequence of segments, making up parts of the missions: + The mission definition is built-up in a hierarchical way. As the topmost element of the hierarchical mission definition, missions are created within the missions node. + Here, one or more segmentBlocks are referenced. These again link to a sequence of segments, making up parts of the missions: @@ -24064,10 +23343,7 @@ The fuel tank volume type should also be used for the wing fuel tank<missions> - containing the - <startCondition> - and a sequence of - <segmentBlockUIDs> + containing the <startCondition> and a sequence of <segmentBlockUIDs> @@ -24076,44 +23352,23 @@ The fuel tank volume type should also be used for the wing fuel tank - grouping multiple - <segments> - and providing overall information concerning the block of segments: + grouping multiple <segments> and providing overall information concerning the block of segments: - constraints in the form of an - endCondition - or given - flightPath - , + constraints in the form of an endCondition or given flightPath, - variableSegments - and the corresponding - variableConditions - in case a segment should be adjusted such to meet the - segmentBlock - 's - endCondition - , + variableSegments and the corresponding variableConditions + in case a segment should be adjusted such to meet the segmentBlock's endCondition, fuelPlanningType - ( - designFuel - , - reserveFuel - , - additionalFuel - ), + (designFuel, reserveFuel , additionalFuel), - segmentDirection - and - numberOfRepetitions - . + segmentDirection and numberOfRepetitions. @@ -24133,16 +23388,13 @@ The fuel tank volume type should also be used for the wing fuel tank - segmentType - , + segmentType, - endConditions - , + endConditions, - constraints - , + constraints, environmentalConditions @@ -24178,11 +23430,7 @@ The fuel tank volume type should also be used for the wing fuel tank<endCondition> - specific end condition for a - segmentBlock - or - segment - (e.g.: an altitude or velocity) + specific end condition for a segmentBlock or segment (e.g.: an altitude or velocity) @@ -24190,11 +23438,7 @@ The fuel tank volume type should also be used for the wing fuel tank<constraint> - specific performance settings for a - segmentBlock - or - segment - (e.g.: a cruise Mach number) + specific performance settings for a segmentBlock or segment (e.g.: a cruise Mach number) @@ -24208,7 +23452,6 @@ The fuel tank volume type should also be used for the wing fuel tank enum: „lt“, „le“, „eq“, „ne“, „ge“, „gt“ - , Examples: @@ -24239,17 +23482,9 @@ The fuel tank volume type should also be used for the wing fuel tank - The mission starts at a position of 0, 0, 0 with 0 velocity, as provided by the - startCondition - of the - mission - node. Furthermore, the environmental conditions are provided: ISA atmosphere with a - deltaTemperature - of 0 [K]. The mission consists of three - segmentBlocks - : a designMission, reserves and the taxiIn - segmentBlock - . + The mission starts at a position of 0, 0, 0 with 0 velocity, as provided by the of the mission node. + Furthermore, the environmental conditions are provided: ISA atmosphere with a deltaTemperature of 0 [K]. + The mission consists of three segmentBlocks: a designMission, reserves and the taxiIn segmentBlock. - The designMission - segmentBlock - is shown below. It provides a set of five segments, together making up a mission with a range of 1000 [nm] or 1852 [km]. The “cruise” segment is the variable segment, which thereby should have a range of: - 1852000 – range(climb) – range(descent) - , provided the taxiOut and takeOff segments are not providing any range credit. The fuel burned during this - segmentBlock - should be added to the - designFuel - , the - segmentDirection - is provided for illustration purposes. + The designMission segmentBlock is shown below. + It provides a set of five segments, together making up a mission with a range of 1000 [nm] or 1852 [km]. The “cruise” segment is the variable segment, which thereby should have a range of: + 1852000 – range(climb) – range(descent), provided the taxiOut and takeOff segments are not providing any range credit. + The fuel burned during this segmentBlock should be added to the designFuel, the segmentDirection is provided for illustration purposes. - The first and second segment are providing input for the part of the - segmentBlock - that doesn’t need simulation. During the taxiOut phase, 50 [kg] of fuel is burned. The takeOff phase has a duration of 30 [sec]. + The first and second segment are providing input for the part of the segmentBlock that doesn’t need simulation. + During the taxiOut phase, 50 [kg] of fuel is burned. + The takeOff phase has a duration of 30 [sec]. - The rest of the segments make-up the flying part of the - designMission - . The climb phase, ending at an altitude of FL330 or 10058.4 [m], provides a constraint-lapse having discrete steps, typical for transport aircraft (a 250 kt / 300 kt / M 0.78 climb profile). Through the - referenceEndconditionUID - “altClimb”, a link to the altitude - endCondition - of the segment at the basis of this climb profile is provided. + The rest of the segments make-up the flying part of the designMission. + The climb phase, ending at an altitude of FL330 or 10058.4 [m], provides a constraint-lapse having discrete steps, typical for transport aircraft (a 250 kt / 300 kt / M 0.78 climb profile). + Through the referenceEndconditionUID “altClimb”, a link to the altitude endCondition of the segment at the basis of this climb profile is provided. @@ -24383,11 +23607,9 @@ The fuel tank volume type should also be used for the wing fuel tank - The cruise phase is not fixed to a certain altitude and has no - endCondition - , since its range is determined by the - segmentBlock - information. The descent phase makes sure the vehicle lands at an altitude of 0 [m]. In this case, since the values are not explicitly provided, it is up to the mission simulation software to determine, when the cruise phase ends and the descent phase starts. + The cruise phase is not fixed to a certain altitude and has no endCondition, since its range is determined by the segmentBlock information. + The descent phase makes sure the vehicle lands at an altitude of 0 [m]. + In this case, since the values are not explicitly provided, it is up to the mission simulation software to determine, when the cruise phase ends and the descent phase starts. - Two more - segmentBlocks - make up the mission. The “reserves” - segmentBlock - provides information for the cruise to alternate airport and loitering phase and the corresponding burnt fuel is considered - reserveFuel - . The mission ends with a landing and taxiIn phase within the “endPhase” - segmentBlock - , of which the burnt fuel is considered - additionalFuel - . The following then holds: - blockFuel - = - designFuel - + - additionalFuel - . + Two more segmentBlocks make up the mission. + The “reserves” segmentBlock provides information for the cruise to alternate airport and loitering phase and the corresponding burnt fuel is considered reserveFuel. + The mission ends with a landing and taxiIn phase within the “endPhase” segmentBlock, of which the burnt fuel is considered additionalFuel. + The following then holds: blockFuel = designFuel + additionalFuel. @@ -26688,13 +25897,7 @@ The fuel tank volume type should also be used for the wing fuel tank - The - centerCowl - is defined by the rotation of a given curve profile (referenced via - curveUID - ) around the - x - -axis. + The centerCowl is defined by the rotation of a given curve profile (referenced via curveUID) around the x-axis. @@ -26782,40 +25985,24 @@ The fuel tank volume type should also be used for the wing fuel tank The following figure shows the basic setup of the guide curves. - They always start at a given ζ-position ( - fromZeta - ) on the profile of the specified start section ( - startSectionUID - ) and end at the ζ-position ( - toZeta - ) on the profile of the subsequent section. - The relative coordinates of the guide curves are specified in - cpacs/vehicles/profiles/guideCurves - and referenced via its - uID - . + They always start at a given ζ-position (fromZeta) on the profile of the specified start section (startSectionUID) and end at the ζ-position (toZeta) on the profile of the subsequent section. + The relative coordinates of the guide curves are specified in cpacs/vehicles/profiles/guideCurves and referenced via its uID. - Note - : Guide curves and profiles must result in a valid curve network. + Note: Guide curves and profiles must result in a valid curve network. - The guide curve points are interpreted as ( - Δr - and - Δx - ) offsets from a cubic polynomial. + The guide curve points are interpreted as (Δr and Δx) offsets from a cubic polynomial. This polynomial serves as a baseline for guide curves between segments located on different radial positions with smooth transitions: - Note - : Currently, the nacelles do not have an explicit guide curve type but employ the standard guide curve definition, which is used in wings and profiles. + Note: Currently, the nacelles do not have an explicit guide curve type but employ the standard guide curve definition, which is used in wings and profiles. Therefore, the parameters have a different meaning: @@ -26840,9 +26027,7 @@ The fuel tank volume type should also be used for the wing fuel tankΔx - Orthogonal offset (translation in - x - -direction) + Orthogonal offset (translation in x-direction) @@ -26968,13 +26153,10 @@ The fuel tank volume type should also be used for the wing fuel tank An engine nacelle is defined by sections, where at least one and up to an infinite number of sections can be specified. Lofting of the nacelle surface along the sections is done in cylindrical coordinates. - The - coordinate origin refers to the center of the fan - , i.e. the sections and their profiles are typically shifted in negative x-direction. + The coordinate origin refers to the center of the fan, i.e. the sections and their profiles are typically shifted in negative x-direction. - Note - : In the current CPACS release, transformations are still labeled as Cartesian coordinates. + Note: In the current CPACS release, transformations are still labeled as Cartesian coordinates. It is current work in progress to explicitly introduce cylindrical coordinates. Until this is implemented in a future CPACS release, the implicit conventions listed below apply: @@ -26992,8 +26174,7 @@ The fuel tank volume type should also be used for the wing fuel tankϑ - Rotation angle around - x + Rotation angle around x @@ -27017,41 +26198,20 @@ The fuel tank volume type should also be used for the wing fuel tank The following example illustrates the setup of a nacelle with 4 sections. - These are rotated by 0, 120, 180 and 240 degrees around the - x - -axis (given by - translation/x - ). - To illustrate the possible transformations, the profile of the upper section is shifted slightly further in the negative - x - -direction ( - translation/y - ), while the lower section has a smaller radial distance from the rotation axis ( - translation/z - ). - In addition, the sections are scaled differently ( - transformation/scaling - ; not shown in the example figures) in order to create a straight trailing edge and to realize a flattened profile near the ground. + These are rotated by 0, 120, 180 and 240 degrees around the x-axis (given by translation/x). + To illustrate the possible transformations, the profile of the upper section is shifted slightly further in the negative x-direction (translation/y), while the lower section has a smaller radial distance from the rotation axis (translation/z). + In addition, the sections are scaled differently (transformation/scaling; not shown in the example figures) in order to create a straight trailing edge and to realize a flattened profile near the ground. - The following example also shows the profile cut-outs due to the radially symmetric inner region of the nacelle defined by the - rotationCurve - . For detailed information, please refer to the documentation of the - rotationCurve - element. + The following example also shows the profile cut-outs due to the radially symmetric inner region of the nacelle defined by therotationCurve. + For detailed information, please refer to the documentation of the rotationCurve element. - The first section is not rotated ( - x=ϑ=0 - ), but shifted vertically in negative direction ( - y=h=-0.257 - ). - The radial distance is given by - z=r=0.365 - : + The first section is not rotated (x=ϑ=0), but shifted vertically in negative direction (y=h=-0.257). + The radial distance is given by z=r=0.365: - The second section is rotated around the - x - -axis ( - x=ϑ=120 - ) as well as scaled by a factor of 1.1 in its profile height: + The second section is rotated around the x-axis (x=ϑ=120) as well as scaled by a factor of 1.1 in its profile height: - The third section is rotated around the - x - -axis by 180° and scaled by a factor of 0.8 in its profile height: + The third section is rotated around the x-axis by 180° and scaled by a factor of 0.8 in its profile height: Short description - The ProfileBasedStructuralElement type containins the - data of a structural element, that are based on 2-dimensional profiles. + + The ProfileBasedStructuralElement type containins the data of a structural element, that are based on 2-dimensional profiles. + There are three approaches to model profile based structural elements: @@ -29724,11 +28879,7 @@ The fuel tank volume type should also be used for the wing fuel tank1. Global beam properties - In the section - globalBeamProperties - the properties - of the structural profile in an equivalent beam representation - are defined. + In the section globalBeamProperties the properties of the structural profile in an equivalent beam representation are defined. @@ -29736,18 +28887,10 @@ The fuel tank volume type should also be used for the wing fuel tank2. Structural 2D profile - The - structuralProfileUID - element refers to the - uID - of the - structuralProfile2D - element. + The structuralProfileUID element refers to the uID of the structuralProfile2D element. As described in the corresponding documentation, this profile is defined by several points in the x-y-space. Two points always form a sheet. - The properties of each sheet are defined in the - sheetProperties - element. + The properties of each sheet are defined in the sheetProperties element. The orthotropy direction of composite materials equals the sheets' x-axis. The orthotropy direction angle equals a positive rotation around the sheets' z-axis as indicated in the picture below (part 3), which shows an example of a wing stringer.: @@ -29760,15 +28903,9 @@ The fuel tank volume type should also be used for the wing fuel tank3. Standard structural 2D profile - Instead of referencing a - structuralProfile2D - element, it is also possible to select a predefined standard profile. + Instead of referencing a structuralProfile2D element, it is also possible to select a predefined standard profile. These profiles are listed in the figure below. - Under - sheetProperties - , only the - standardProfileSheetID - (equals S1, S2, ...) must now be specified along with a corresponding length. + Under sheetProperties, only the standardProfileSheetID (equals S1, S2, ...) must now be specified along with a corresponding length. @@ -30556,18 +29693,10 @@ The fuel tank volume type should also be used for the wing fuel tank - with - c = cornerRadius - and - r = heightToWidthRatio - . + with c = cornerRadius and r = heightToWidthRatio. - Example: Rectangle with - cornerRadius - =0.125 and - heightToWidthRatio - =0.5 + Example: Rectangle with cornerRadius=0.125 and heightToWidthRatio=0.5 @@ -31102,38 +30231,18 @@ The fuel tank volume type should also be used for the wing fuel tank - First, the reference system is defined via - referenceSectionUID - , for which in this example the section with - uID="engine_nacelle_fanCowl_section1" - is referenced. - This in turn contains a - transformation - (not shown here), for example a translation by - z=0.4 - and a scaling, where the - x - -direction is stretched by a factor of two. + First, the reference system is defined via referenceSectionUID, for which in this example the section with uID="engine_nacelle_fanCowl_section1" is referenced. + This in turn contains a transformation (not shown here), for example a translation by z=0.4 and a scaling, where the x-direction is stretched by a factor of two. The rotation curve is now described in this reference system. - It is predefined in the profile library and referenced via a its - uID - . - Note that the curve is defined in the range - x=[0,..,1] - in order to be reasonably transformed by the reference system. + It is predefined in the profile library and referenced via a its uID. + Note that the curve is defined in the range x=[0,..,1] in order to be reasonably transformed by the reference system. Next, the blending from the rotated profile of the nacelle segment to the rotation curve is defined. - The corresponding start and end points are given in curve coordinates - zeta - of the corresponding profiles. - Note that the lower part of the segment profile counts from - zeta=[-1,..,0] - and the upper part counts from - zeta=[0,..,1] - . + The corresponding start and end points are given in curve coordinates zeta of the corresponding profiles. + Note that the lower part of the segment profile counts from zeta=[-1,..,0] and the upper part counts from zeta=[0,..,1]. In between, the blending is linear. @@ -31476,17 +30585,8 @@ The fuel tank volume type should also be used for the wing fuel tank1. General - The - massBreakeDown - is subdivided in - designMasses - , - fuel - , - payload - and - mOME - (operating empty mass). + The massBreakeDown is subdivided in designMasses, fuel, + payload and mOME (operating empty mass). designMass @@ -31494,9 +30594,7 @@ The fuel tank volume type should also be used for the wing fuel tankThe design mass is a description from TLARs and can be understand as design criteria. - fuel - and - payload + fuel and payload The fuel and payload mass are the maximum masses which can be achieved. Full fuel tanks, all passengers on @@ -31535,27 +30633,13 @@ The fuel tank volume type should also be used for the wing fuel tank - That - massdescription - can be found at the - designMasses - direct under each item. At the - fuel - , - payload - and - mOME - under massDescription in each item and sub item. + That massdescription can be found at the designMasses direct under each item. + At the fuel, payload and mOME under massDescription in each item and sub item. - For the clean up the - mOME - there is consisting a script witch is programmed in Matlab but - also as standalone vision available. Setting for that tool can - be done under - toolspesifics/cmu - . + For the clean up the mOME there is consisting a script witch is programmed in Matlab but also as standalone vision available. + Setting for that tool can be done under toolspesifics/cmu. @@ -31920,13 +31004,8 @@ The fuel tank volume type should also be used for the wing fuel tank - Note that rotor blade geometries are only referenced and not - defined in the child nodes of the rotor element. Refer to the - documentation of rotorBladesType ( - Empty#T/rotorBladesType - ) and wingType ( - Empty#T/wingType - ) for information on the definition of rotor blade geometries. + Note that rotor blade geometries are only referenced and not defined in the child nodes of the rotor element. + Refer to the documentation of rotorBladesType (Empty#T/rotorBladesType) and wingType (Empty#T/wingType) for information on the definition of rotor blade geometries. The following figure shows the transformations to be applied to rotorBlade geometries to visualize them in the rotor @@ -32220,13 +31299,8 @@ The fuel tank volume type should also be used for the wing fuel tank - Note that rotor blade geometries are only referenced and not - defined in the child nodes of the rotor element. Refer to the - documentation of rotorBladesType ( - Empty#T/rotorBladesType - ) and wingType ( - Empty#T/wingType - ) for information on the definition of rotor blade geometries. + Note that rotor blade geometries are only referenced and not defined in the child nodes of the rotor element. + Refer to the documentation of rotorBladesType (Empty#T/rotorBladesType) and wingType (Empty#T/wingType) for information on the definition of rotor blade geometries. The following figure shows the transformations to be applied to rotorBlade geometries to visualize them in the rotor @@ -34523,12 +33597,9 @@ The fuel tank volume type should also be used for the wing fuel tank - DEPRECATED - : The - isLink - attribute is set to optional to ensure the compatibility of older data records. However, since the linking character is explicitly defined by the - stringUIDBaseType - , the attribute is superfluous and will therefore be completely omitted in future versions. + DEPRECATED: + The isLink attribute is set to optional to ensure the compatibility of older data records. + However, since the linking character is explicitly defined by the stringUIDBaseType, the attribute is superfluous and will therefore be completely omitted in future versions. @@ -34568,14 +33639,14 @@ The fuel tank volume type should also be used for the wing fuel tank DEPRECATED: As of - CPACS + CPACS version 3.3, the mapType attribute is set to optional to ensure the compatibility of older data sets. However, since the type is uniquely defined via the XSD, the attribute is superfluous and will therefore be completely omitted in the next major release (Note: requires TiXI >= 3.3). Please contact the - CPACS + CPACS team if for any reason you see a long-term need for the mapType @@ -35167,11 +34238,11 @@ The fuel tank volume type should also be used for the wing fuel tank - A profile based on superellipses is composed of an upper and a lower semi-ellipse, which may differ from each other in their parameterization. The total width and height of the profile is always 1, since scaling is performed after referencing (e.g., in the fuselage). + A profile based on superellipses is composed of an upper and a lower semi-ellipse, which may differ from each other in their parameterization. + The total width and height of the profile is always 1, since scaling is performed after referencing (e.g., in the fuselage). + - This - lowerHeightFraction - describes the portion of the lower semi-ellipse on the total height. + This lowerHeightFraction describes the portion of the lower semi-ellipse on the total height. The resulting profile is defined by the following set of equations: @@ -35186,39 +34257,30 @@ The fuel tank volume type should also be used for the wing fuel tank The following examples indicate the various possibilities of parametric profiles: - Example 1 - : ( - mUpper,nUpper,mLower,nLower, lowerHeightFraction - ) = (0.5; 2; 5; 3; 0.25) + Example 1: + (mUpper,nUpper,mLower,nLower, lowerHeightFraction) = (0.5; 2; 5; 3; 0.25) - Example 2 - : ( - mUpper,nUpper,mLower,nLower, lowerHeightFraction - ) = (2; 2; 2; 2; 0.5) = a circle + Example 2: + (mUpper,nUpper,mLower,nLower, lowerHeightFraction) = (2; 2; 2; 2; 0.5) = a circle - Example 3 - : ( - mUpper,nUpper,mLower,nLower, lowerHeightFraction - ) = (1; 1; 1; 1; 0.5) = a square / diamond + Example 3: + (mUpper,nUpper,mLower,nLower, lowerHeightFraction) = (1; 1; 1; 1; 0.5) = a square / diamond - Note - : For exponents that are infinitely large, the superellipse converges to a rectangle. However, the value - Inf - is not a valid entry at this point. Use the - square - element instead. + Note: For exponents that are infinitely large, the superellipse converges to a rectangle. + However, the value Inf is not a valid entry at this point. + Use the square element instead. @@ -37260,8 +36322,7 @@ The fuel tank volume type should also be used for the wing fuel tank - defines which condition(s) are variable within the segment (must be one of the defined - endConditions for the segmentBlock) + defines which condition(s) are variable within the segment (must be one of the defined endConditions for the segmentBlock) @@ -37317,29 +36378,12 @@ The fuel tank volume type should also be used for the wing fuel tank - The - vehiclesType - contains all vehicle-specific - data. + The vehiclesType contains all vehicle-specific data. - This includes the vehicle itself (i.e. - aircraft - and - rotorcraft - ). Furthermore, components - (e.g. - engines - , - structuralElements - , etc.) - as well as physical properties of - materials - and - fuels - can be predefined for easy and consistent reuse via - uID - -references. + This includes the vehicle itself (i.e. aircraft and rotorcraft). + Furthermore, components (e.g. engines, structuralElements, etc.) + as well as physical properties of materials and fuels can be predefined for easy and consistent reuse via uID-references.