Coding for 3D-MTRAC to 1D/2D calculated channels

[DiVe]

Dear All,
there is an ongoing discussion on the calculation of the 1D TRAC (like in ECE R135, WS Dummy certification) displacement
from a 3D MTRAC in the WS.
The ancorage point of the 1D TRAC on the spine was different as in the current 2D and 3D devices.
So the current 2D instrumentation can only deliver an estimation of the 1D length change/deflection as the second rotation (ANX) is missing.
For the coding of the channels we have now the dilemma that we can not clearly distinguish between the measurements:

1D: compression was named "DSY" (DSY_1D) (see figure WS: ISO_WS_3_162p2)

2025-02-25 17_42_26-XnView - [ISO_WS_3_162p2_20170420.emf].png (25.61 KiB) Viewed 16652 times

2D: length DC0 + ANZ -> DSY (DSY_2D) for EuroNCAP and also change in length DS0 (used as 1D "equivalent" sometimes;
see figure WS: ISO_WS_2_162p2)

2025-02-25 17_43_45-XnView - [ISO_WS_2_162p2_20170420.emf].png (27.1 KiB) Viewed 16652 times

Now the coding question is, how to code the potential measurements from a 3D-MTRAC device.
3D: DC0, ANZ, ANX -> can deliver based on calculation DSY_1D equivalent, but also a DSY_2D
How to name these channels? Both are a "DSY" variant.

The topic is also related to the coding for RIBEye:
see viewtopic.php?p=1382

Kind regrads,
Dirk

[DiVe]

Dear All,
please find here some proposals for the coding approach.
Actually, these "new" codes are only relevant for the calculated channels.
The base channels could be named in the same way for 2D, 3D
as they are the same measurements (as long as the geometric design is the same).
2D and 3D will measure DC0 and ANZ.
The 3D adds an ANX channel.
(1D will get DSY directly with class P and no ANZ or ANX).

Base code like:
11TRRILE01WSDC0P


a) Variant 1A: coding the device type (2D/3D) in FL2:

A_Coding_with_FL2.png (35.51 KiB) Viewed 12561 times

pro
- same rib "height" coding (1,2,3)

con
- overlap with rxisting redundant codes
-introduce new FL2 codes

b) Variant 1B: coding the device type (2D/3D) in FL2:

B_Coding_with_FL2.png (35.3 KiB) Viewed 12561 times

pro
- use existing code parts for FL1
con
- introduce new FL2
- recode from 01/02/03 to UP/MI/LO

c) Variant 2: coding the device type (2D/3D) in ML:

2_Coding_with_ML.png (37.59 KiB) Viewed 12561 times

pro:
- Fine Locations will be untouched

con:
- introduce new ML
- divergent ML to base channels

Any more ideas to discuss?

[DiVe]

Dear All,

in the discussion at the meeting (2025-04-29) the following decisions have been made:
- the coding for the existing sensors and calculations should be untouched
(existing processes and existing data will still be valid regarding the coding)
- the new approach for the calculated channels for the 3D should use the Variant 2

An new coding proposal for the calculated channels from a 3D MTRAC is:

2_3D_Coding_with_ML.png (12.4 KiB) Viewed 12540 times

SR3D : Shoulder Rib DSY from 3D
TR3D : Shoulder Rib 01/02/03 DSY from 3D
AR3D : Abdominal Rib 01/02 DSY from 3D

The 3D calculation (see ISO 21002 new revision soon) will also
provide: DSX, DSZ and DSR

The change in length (DS0) of the 2D and 3D device will be the same
as the geometry is identical. So, no need for a new/special code.

The DSY calculation based on the 2D formula for the WS (EuroNCAP TB021/CP005) can
also be derived from the 3D device based on the same 2D formula.
No need for a code change.
Example for TRRILE01:

2D_Code_Example_TRRILE01.png (9.09 KiB) Viewed 12400 times

The DSY (change in length) of the 1D device as needed in ECE R135 testing and
the WS certification (ISO 15830) can also be calculated from the 3D device.
The basic "DS0 change in length" of the 2D (and identical for the 3D) device is
not identical to the change in length if the 1D device (coded there as DSY).

A 3D device will be capable of calculation the 1D change in length.
The formulas are under development for a revision of the ISO 21002.

May here a separate code for "1D change in length from 3D device" will be sensible
as the DSY codes will already be used in the 2D conversion.
Some coding proposals for this purpose from my side for the discussion:

1D_from_3D_coding_proposal.png (7.09 KiB) Viewed 12539 times

Kind regards,
Dirk