EQX Schema v1.5

Equipment Exchange (EQX) Data Format Description
Version 1.5
Kistler, July 2016

1. History
The format is developed based on the results of the AK Equipment Exchange from 2007-02-07, version 0.9 (see [1]) and example files of different manufacturers. First prototypes have been realized by Delphi and Messring.

Version 1.0 is developed in Dec 2009 by the companies KT Automotive, Messring, MSC and Kistler. Intention of the 1.0 version is the ability of the format to exchange a complete set of sensor and dummy data from one database to another without loss of information. Support of EQX version 1.0 is realized since CrashDesigner V2.6.1 by KT Automotive.

Version 1.1 is a compatible enhancement to V1.0 in Oct 2010 by KT Automotive. It additionally supports the exchange of test setups with ISO attributes and additional company specific attributes for the test and the test objects. It was requested by users to realize the exchange with 3rd party test preparation software packages. Support of EQX 1.1 is provided in CrashDesigner V2.7.1 by KT Automotive.

Version 1.2 is a compatible enhancement to V1.1 in Jul 2011 by Kistler. Optional attributes are allowed on sensor axes and calibration entries and additional fix attributes are defined to fully support test setup exchanges.

Version 1.3 is a compatible enhancement to V1.2 in May 2012 as a result of a stakeholder meeting at TRW on 2012-03-15. It contains additional optional attributes for calibration entries and additional SensorGroup Categories.

Version 1.4 is a compatible enhancement to V1.3 in Jul 2014 by Kistler. Exchange of digitally calibrated sensors, operated in LSB (least significant bit) instead of mV is added. ID module types are enhanced. Elements to specify the bridge resistors are added.

Version 1.5 is a compatible enhancement to V1.4 in Jul 2016 as discussed and agreed in a web meeting on 2016-05-11 and a meeting at Messring on 2016-06-22 with participants from ZF/TRW, Kistler, DTS, Hentschel, Messring, measX, IAT.
Changes to version 1.4
SensorGroup enhancements:
· New category ‘Equipment’ for the exchange of peripheral equipment.
· New element ‘Path’ to specify structure information for a group.

SensorAxis enhancements:
· New scaling method ‘Linear with Offset’.
· New connector types ‘Tajimi 7pol flat’ and ‘Micro D 15pol’.
· New Electrical methods ‘Half Bridge Poti’, ‘Quarter Bridge’, ‘High Voltage Input’.
· New element ‘NominalValue’ as a complement to the ‘MinRange’ and ‘MaxRange’ elements in an asymmetrically used context.
· New elements ‘SWOffsetCompensationType’, ‘SWOffsetCalculationStartSec’, ‘SWOffsetCalculationEndSec’, ‘SWOffsetFixValue’, ‘SWFilterClassType’, ‘SWFilterAdHocFrequency’ for a detailed specification of software offset and filter corrections.
· New elements ‘FiringDuration’, ‘FiringVoltageLimit’, ‘FiringCurrentLimit’ for an enhanced exchange of timer channel parameters.

CalHistoryEntry enhancements:
· New flag ‘ReferenceCalibration’ to mark a calibration to be the master for the deviation verifications.

Attachment enhancements:
· New attribute ‘Type’ to optionally specify whether the attachment is a calibration sheet, data sheet or image.
Changes to version 1.3
SensorAxis enhancements:
· New element ‘EngineeringUnit’ for SensorAxis and CalHistory elements.
· New possible values ‘DiMod’ and ‘Microdau’ for IDModuleType elements.
· New elements ‘BridgeResistorPinpPexc’, ‘BridgeResistorPinpNexc’, ‘BridgeResistorNinpPexc’, ‘BridgeResistorNinpNexc’ for SensorAxis elements.
Changes to version 1.2
SensorAxis enhancements:
· New elements ‘LinearityDeviation’ and ‘StandardDeviation’ for SensorAxis and CalHistory elements.
· New elements ‘MaxSensitivityDeviation’, ‘MaxLinearityDeviation’ and ‘MaxStandardDeviation’ to exchange accepted limits.

SensorGroup enhancements:
· The choice for the ‘Category’ has been enhanced by the ‘TestBench’ and the ‘MeasurementDevice’ category.
Changes to version 1.1
SensorAxis enhancements:
· The elements ‘ReadoutEnabled’ and ‘ConversionEnabled’ have been added to SensorAxis elements.
· The element ‘Attribute’ has been added to CalHistory elements as well as for SensorAxis elements. See specific attribute names for analog trigger definition below.
· The element ‘ConnectorId’ has been added to SensorAxis elements, enabling to exchange information about sensor axes connected with the same multi-channel connector.
Changes to version 1.0
SensorGroup enhancements:
· The element ‘Attribute’ has been added to SensorGroup and Sensors elements.
· The choice for the ‘Category’ has been enhanced by the ‘TestSetup’ category.
Changes to version 0.9

General changes:
· The element ‘Data format edition’ has been renamed to ‘DataFormatEdition’ to be consistent with the naming of other elements
· The Address type is defined as a set of attributes.
· The elements ‘AttachmentX’ and ‘AttachmentXDescription’ have been replaced by a new type ‘Attachment’, which may be added unbounded.
· The element ‘Remark’ is moved from the header section to the base type of all grouping types. So general remarks are part of the ‘Sensors’ root element, now.

SensorGroup changes and enhancements:
· Sensor groups may represent different types like dummies, multi-axis sensors or just nested groups of dummies or sensors. To separate those cases, an additional element ‘Category’ with an according enumeration has been added, as it is already used in some of the example files.

SensorAxis changes and enhancements:
· The element ‘Electrical_Methode’ has been renamed to ‘ElectricalMethod’ to be consistent with the naming of other elements. The underlying enumeration has been enhanced, please see [2] for details. An additional element ‘ScalingMethod’ respects non-linear transformations.
· All elements except the ‘Name’ and ‘UUID’ are optional, now. A sensor axis may optionally be used for arbitrary dummy or car channels, even without a physical sensor behind like airbag timer channels or constant channels. Additionally, some sensor axes may not know about their mounting location or orientation.
· The new element ‘Enabled’ allows the specification of disabled channels / sensor axes.
· The location specification has been enhanced by a long name and company specific code and long name.
· The new element ‘Technology’ specifies a certain technology type of sensor, e.g. RES for resistive sensors, PES for piezo electrical sensors
· The enumeration ‘IdModuleType’ has been reduced to the actually used id modules. A new element ‘TedsType’ marks sensors with TEDS information.
· The new element ‘Status’ specifies a sensor status – detailed information to the ‘Usable’ flag.
· The shunt parameters are enhanced by the new flags ‘ShuntCheckPos’ and ‘ShuntCheckNeg’ specifying whether the shunt measurement is active or not. The shunt check tolerance is now specified in % of the reference value instead of mV/V.
· The new element ‘ExcitationVoltage’ specifies the excitation used for this channel which may derive from the excitation used for the latest calibration (‘SensitivityVoltage’). In comparison to that, the ‘ExcitationVoltageMin’ and ‘ExcitationVoltageMax’ elements specify the allowed voltage range given by the sensor manufacturer.
· The new element ‘PreferredRange’ holds the CAC (Channel Amplitude Class) of the channel, which may differ from the already defined maxRange. While the maxRange specified the range of linearity of the sensor output, the preferred range controls the ideal amplification. Signals above the preferred range will run into overdrive while signals much lower than the preferred range will not use the available resolution of the measurement device.
· The reference to a device channel is added in the new element ‘DeviceChannelName’. The content is a unique identification of a device channel according to the device manufacturer naming convention.
· The calibration elements are enhanced by the ‘CalPersion’ and the ‘CalRemark’. To transfer also a calibration history, further entries containing old calibration data may be added unbounded as ‘CalHistory’ elements. The new element ‘CalVersion’ is an increasing number usable for calibration entry sorting. Additional calibration values may be added for non-linear sensors like IRTRACC or cubic polynomial calibrated displacement sensors (see the description of the ScalingMethod type enumeration). The ‘CalDate’ type now refers to the standard schema type ‘date’ to avoid proprietary formatting and provide format checking by schema.
· Some further optional elements handle constant channels and timer channels specifications.
· The elements ‘AttachmentX’ and ‘AttachmentXDescription’ have been replaced by a new type ‘Attachment’, which may be added unbounded.
· The element ‘Direction’ has been renamed to ‘AxisDirection’, the ‘MountingPolarity’ is specified by an own element. Any inversions due to sensor wiring are specified by an element ‘ElectricalPolarity’.
· The ‘ConnectorPinX’ elements have been replaced with unbounded ‘ConnectorPin’ definitions, each identified by id which is not necessarily a number in 1-10 anymore.

2. Format description
File Structure
The data exchange is done via an XML file with the suffix ‘.e2x’. The XML file follows the XML schema definition, which contains a detailed description of the current types and elements (see [2]).

Additional related files like data sheets, calibration sheets or images can be exchanged together with the XML structure. Those are referred by the ‘Attachment’ elements in the XML file. The content of the Attachment element specify the path relative to the current directory of the XML file. Best practice for the exchange is to place the attached files on a subfolder named similar to the .e2x file but without the suffix.

Sensor Exchange
A sensor should be specified as SensorGroup element of category ‘Multi-Axis Sensor’. Single axis sensors use the same category but add only one axis.

The order of Sensor Axis elements within the SensorGroup needs to be respected carefully. Usually they should be ordered by 1st Dimension and 2nd Direction.

Sensors may be specified multiple times in a file, e.g. as a part of a multi axis sensor and as a part of dummies. Only one specification needs to be complete, others may just refer to the UUID and name of the sensor. Complete sensor definitions need at least the specification of the Model and the ElectricalMethod.

The latest calibration should be added direct to the SensorAxis element. Older or alternative calibrations may be added as CalHistory elements with decreasing CalVersion numbers.

Calibration labs should check new calibrations against the latest calibration of the history with ReferenceCalibration set to true (if available) or the calibration information directly at the SensorAxis as fallback. The tolerance for the sensitivity may be provided via the MaxSensitivityDeviation element. Additional verifications are requested, if the elements MaxLinearityDeviation and MaxStandardDeviation are defined.

Dummy Exchange
Dummys and other channel groups are SensorGroup elements of category ‘Dummy’. Each channel is specified as SensorAxis element. Assigned sensors are referred via the UUID and Name element.
Channels without sensors should be named similar to their ‘LocationCode’. ‘FiringMode’ and ‘FiringDelay’ should be specified for timer channels only. ‘ConstInValue’ and ‘ConstInReadOnly’ should be specified for constant channels only (e.g. Pendulum mass).

Peripheral Equipment Exchange
General equipment as balances, tilt sensors or data loggers should be specified as SensorGroup element of category ‘Equipment’ with a single SensorAxis sub-element. If assigned to a dummy, these specific SensorGroup elements may be added to a dummy SensorGroup element.
Test Setup Exchange
Test setups should be exchanged as SensorGroup element of category ‘TestSetup’. The substructure hold test objects on first level and seat positions in second level. A nested structure of other SensorGroup elements reflects the structure of the test setup.
Each SensorGroup level can hold specific attributes. The ‘Attribute’ keys for ISOMME data should follow the convention of ISOMME, e.g. ‘Customer test ref. number’. The keys for numerated ISOMME data should follow the convention of ISOMME without number, e.g. ‘Velocity test object’, ‘Name of test object’ and should be assigned directly to the according test object SensorGroup element one level below the test setup SensorGroup element. Customer specific keys are allowed, but possibly need registration to the importing system.

The following additional attribute keys are known yet:
Attribute Key
Value Format
Unit
Element
Description
Pre trigger time
xxx.yyyy
sec
SensorGroup, Category TestSetup
The required pre trigger time for data acquisition
Post trigger time
xxx.yyyy
sec
SensorGroup, Category TestSetup
The required post trigger time for data acquisition
Analog trigger
[lt|gt] xxx.yyyy
Sensor unit
SensorAxis
Defines an analog trigger on a specified sensor. The trigger is launched if the sensor value is above (gt) or below (lt) the specified threshold.
BaudRate
int
Baud
SensorAxis
Baud rate of a CAN logger channel
BusTermination
[true|false]

SensorAxis
True if the CAN bus of a logger channel should be terminated by the device

3. Examples
The example [3] shows a H3 dummy. It contains a SensorGroup element of category ‘Dummy’ containing Sensor elements referring to the dummy channels. The sensor axes are just referred by name, as the detailed sensor axis information is added in the context of the SensorGroup of type ‘Multi-Axis Sensor’. In a general case, the axes of a multi axis sensor need not be referred in the same order inside a dummy or some axes may not be used. But for the sensor import, it is necessary to import the complete axes specification with the correct order into the database.

The example [4] shows an export of a sensor query of cubic polynomial sensors. The calibration sheets of some sensors are attached and exist as file parallel to the e2x.

Example [5] shows the export of a small test setup, containing ISO attributes.
4. References
[1]
AKEQEX_070207_Wuppertal_Delphi_DArp_Attributliste.xls
Description of attributes, version 0.9
[2]
EquipmentExchange.xsd
The XML schema definition
[3]
Dummy 9.zip
An example for dummy exchange, version 1.0
[4]
Sensors.zip
An example for a multi axis sensor exchange list, version 1.0
[5]
Tests-1.1.zip
An example for a test setup exchange list, version 1.1