Interface Structure

The REXS file describes a concrete instance of a gearbox model or sub-model. In essence, it consists of a list of components, attributes, and relations.

Description of REXS files

File format

  • File format: XML
  • Encoding: UTF8 with byte-order-marker (BOM)
  • The file must be well-formed
  • All XML tags are defined in English
  • Generated interface files must comply with the associated XML schema.
  • The .rexs file format should be used for the XML file.
  • The XML validation schema is available in the REXS database
  • Alternatively, a ZIP archive can also be used; see REXS .zip files (.rexsz)

Model structure

The interface describes a model which can be identified using the following characteristics (metadata):

  Feature Description
Part of the REXS file version

Version of the REXS interface.

Format: mainversionnumber.subversionnumber

Example: version="1.2"
applicationId Name of the application that generated the XML file; e.g., "FVA-Workbench."
applicationVersion Version of the application.
date

Time at which the file was created.

Date and time according to ISO 8601 in the following format:
"yyyy-mm-ddThh:mm:ss+<offset to UTC>"
Example: 2016-06-03T11:35:17+01:00
applicationLanguage

Optional: specification of the language used in the application

Language code according to 639-1
Example: applicationLanguage="en"
Example REXS file metadata | XML syntax
<model version="1.0" applicationId="FVA-Workbench" applicationVersion="5.0.0" date="2016-06-03T11:35:17+01:00" applicationLanguage="en">
		<relations>...</relations>
		<components>...</components>
</model>

Components & attributes

A component describes a machine element (e.g., cylindrical gear) or part of a machine element (e.g., shaft section) and is described by a set of attributes (parameters; e.g., number of teeth of a cylindrical gear).

Schematic diagram of the relationship between components and attributes
Example: a bevel gear stage component with shaft angle and axial offset attributes.

Relations

Relations consist of references to components and reflect the structure of the model or sub-model. All components connected by relations must be present in the model.

Schematic diagram of the relationship between relations and components
Example: connection between shaft and gear components via an assembly relation

Naming convention

  • Names (IDs) are assigned in English
  • Names are written in lowercase
  • A '_' is used to separate multiple words
  • The following characters are permitted: "a-z, 0-9, ‚_‘"

Example attribute ID: spiral_angle_pitch_direction

Example component ID: gear_casing

File and folder references

Different use cases may make it necessary to reference additional files or folders in a REXS model. Examples include assembly FE and CAD data, or additional files for describing the gears, such as a GDE file or Klingelnberg neutral data files. References are made using corresponding attributes (e.g., "folder" or "gde_file"). In general, the following applies for these references:

  • References can include relative or absolute paths,

  • The reference level for relative paths is always the REXS *.xml file (*.rexs file).

Notes:
  • To avoid problems when transferring REXS models, .rexsz is the recommended format for referencing other files (see next section).
  • Absolute paths significantly affect the transferability of a REXS model, as the recipient must have access to the same folder structure used by the sender.

REXS .zip files (.rexsz)

The .rexsz format can be used to save the standard .rexs XML file and other related data (files, folders) together as a single .zip archive. References within the .rexsz file must always use relative paths.

Therefore, either a single .rexs (XML) file or a .rexsz (ZIP) file to can be used to represent a REXS model.

Referencing FE and CAD files

For details on referencing FE and CAD files, see "Modeling Assembly Groups."

Referencing GDE files

The Gear Data Exchange (GDE) format is an established interface format for gear data (see VDI/VDE 2610). An associated GDE file can be specified to supplement the description of a cylindrical gear in the REXS model. GDE files are referenced using the "gde_file" attribute of the cylindrical_gear/ring_gear.

Notes:
  • The GDE file may only include one gear.
  • Additional information required for positioning the gear in REXS:

    • Position and orientation of the gear ("Coordinate System"),

    • Orientation of the reference side ("datum_face_orientation" attribute).

  • There is some overlap between the parameters in REXS and GDE. Each application must determine how to manage this and check the consistency of the information, if necessary.

Referencing Klingelnberg neutral data files

The Klingelnberg neutral data format is an established interface for the geometry and manufacturing parameters of bevel gears. An associated Klingelnberg neutral data file can be specified to supplement the description of a bevel gear in the REXS model. Klingelnberg neutral data files can be referenced using the "klingelnberg_neutral_data_file" attribute of the bevel_gear.

Notes:

  • If the model includes multiple bevel gear stages, the file path must include a unique folder name.

  • Additional information required for positioning the gear in REXS:

    • Position and orientation of the gear ("Coordinate System"),

    • Orientation of the cone tip ("bevel_cone_orientation" attribute).

  • There is some overlap between the REXS parameters and the Klingelnberg neutral data. Each application must determine how to manage this and check the consistency of the information, if necessary.

Alternatively, or additionally, a so-called Klingelnberg 3D neutral data file can be used. This includes the flanks of the bevel gear as a 3D point cloud. Klingelnberg 3D neutral data files are referenced using the "klingelnberg_3d_neutral_data_file" attribute of the bevel_gear.

Notes:

  • If the model includes multiple bevel gear stages, the file path must include a unique folder name.

  • The neutral data file must also be specified in the "klingelnberg_neutral_data_file“ attribute (abbreviated if necessary).

Rules for assigning units

The associated units are determined for each numerical attribute, if applicable. Specification in different units is not allowed. Units should be assigned according to SI units. If other units have gained acceptance in engineering practice, they will be accepted; e.g., "revolutions per minute."

The list of possible units can be viewed in the REXS database.

Changes from REXS version 1.3
The unit symbol for degrees is now "deg" instead of "°"

Convention:

  • Absolute temperatures must always be specified in °C.
  • Temperature differences must always be specified in K.

Rules for assigning the unit ID:

  • A maximum of one SI prefix is added before the unit. Example: mm
  • Use a space to identify multiplication of units. Example: N m = N ∙ m
  • Powers are represented by ^. Example: m^2 = m2
  • Fractions are represented by /. Use parentheses to indicate multiplication in the denominator. Example: kg / (m^2 s^3) =

 

Permitted data types

The following data types are available for attributes:

Data type Details
scalar Scalar values
boolean true, false
string  
integer  
floating_point Maximum number of significant digits: 15
enum Has a specified value range
file_reference Reference to a file or folder (relative or absolute)
array One-dimensional array of values
floating_point_array  
integer_array  
boolean_array  
string_array  
enum_array
Changes from REXS version 1.3
The enum_array data type is new. Array of enum values
matrix Two-dimensional array of values, where each row has the same length
floating_point_matrix  
integer_matrix  
boolean_matrix  
string_matrix  
array_of_arrays Two-dimensional array of values, where the rows can have different lengths
array_of_integer_arrays
Changes from REXS version 1.3
The array_of_integer_arrays data type is new

Value range

For numerical attributes, the permissible domain is specified in interval notation. The following convention applies:

  • Opening bracket: interval lower limit
  • Closing bracket: interval upper limit

As well as:

  • Parentheses: limit is not included in the interval (< / >)
  • Brackets: limit is included in the interval (<= / >=)

Examples:

Value range - "value_range" Notation
0 < value (0; ∞)
0 <= value < 1 [0; 1)
-90 <= value <= 90 [-90;90]
Indefinite (-∞; ∞)

The value range for enum attributes is also included in the attribute database.

Extensibility of the interface

The standard interface can be extended with mutually agreed data. This makes it possible to consider special requirements for exchanging data between two software environments. However, the standardized part of the model must comply with the requirements of the REXS specification. If the additional data is omitted, the remaining data should form a valid REXS interface file that describes a coherent model. Each application can then determine whether to use the additional information or only the standardized data.

Specifically, the interface file can be extended to include new attributes and component types. Software that supports the REXS standard should be able to ignore non-standardized extensions during import.

If bilaterally agreed extensions to the REXS standard are to be made, the following naming convention must be observed:

  • Attribute/component IDs must begin with "custom_“

  • The following schema is recommended: "custom_company_application_factor” or “custom_software_flag_xy”

Managing calculation attributes

For many physical parameters, there are a few (standardized) calculation methods and many proprietary methods. Example: rolling bearing service life.

A separate attribute is created for each (standardized) calculation method:

  • nominal_rating_life_rotations_din_iso_281

  • nominal_reference_rating_life_rotations_din_26281

  • ...

The year of publication should be included in the attribute ID to distinguish between different versions of a standard, such as:

  • application_factor_for_fatigue_load_vdi_2736_2014

Managing missing attributes

Default values are not defined for missing attributes in a REXS model. By default, missing attribute values should also be interpreted as such when importing REXS models. They must then either be specified by the user or calculated (e.g., torque at the output).

Each application can decide to offer program-specific default values for missing attributes during import.