TAF/TAP TSI

Yes, I agree that there is a way to encode multiple units by using the existing TractionMode.

But the problem is, that TractionMode is not designed for this purpose, and it means that the same values 11 and 12 (for instance) of TractionMode will have very different meanings, depending on TypeCode2 of LocoTypeNumber. We generally don't like this situation, when the same value can have different meanings.

However, if several stakeholders have already implemented it this way (as it seems from all your comments) then it's ok, for the sake of interoperability SNCF Réseau should also proceed in the same way.
=> I withdraw this CR.

(the coding of TractionMode in this situation should be clearly stated in the Sector Handbook)

Hi everyone,

Concerning TCR ID i think it may be useful in the future (when all TCRs would have been published using TCR messages and standard TCR ids).

It could not only be used for PathAlteration process, but in initial path request process as well : when the IM answers with a path offer that doesn't fit exactly with the request, because of a planned TCR.
Moreover, a Path Alteration may be triggered not only in the case of an interruption (with alternative route) but also in case of a delay, if the same route is used but the path has to be rebuilt with a different speed, etc. In this case there is no interruption.
So, if some IMs want to use a specific code for ReasonOfReference in RPTID, i think it can be included in the list...

SŽCZ suppert this CR.

Miloš Futera (SŽCZ)

Dear Wolfgang.

1) SŽDC supports CR and proposed codelist.

2) Regarding national codes. I generally agree that IM code is better than countrycode - but in a lot of codelist is today used simmilar approach (e.g. TrainActivity) so if there is change - it shall be done everywhere.

3) regarding TCR ID in PathAlteration Process. IM sends PathNotAvailableMessage where IM can identify TCR in element InternalReferenceIdentifier. So Ru knows identification of TCR. If there is need to transmitt interruption ID inside Message PathRequest or PathDetails maybe would be better to use Element InteruptionInformation instead of RelatedPlannedTransportIdentifier.

...

SŽCZ has no objections against CR - any IM can make any optional element mandatorry on its infrastructure.

SŽDC is not in favour of putting "Legal text into XSD"   We feel that just adding of word "Normally" into annotation will be enough in this case (if necessary). So new annotation may be if necessary as follows

" <xs:element name="SerialNumber" minOccurs="0">
     <xs:annotation>
      <xs:documentation>3 digits representing the serial number of the traction of the series. Normally not used in Planning</xs:documentation>
    

Miloš Futera (SŽCZ)

Dear colleagues,

SŽCZ does not support this CR. If we will use TractionMode mandatory only for "non-units" it will be in fact "contitional mandatory" and it may open issues when to use it and when not use it.

Existing structure of XSD solves also usecase of more units in one train. 3 units can be and are coded as 11 (unit 1), 12 (unit2), 13.  See picture (from SŽCZ  regulation regarding TAF TSI).

Miloš Futera (SŽCZ)

...

ProRail has no opnion about this CR since we don't have trains with a tilting function in the Netherlands

SŽCZ: we support CR generally. I also feel that tilting in this usecase shall be parameter of PlannedTrainTechnicalData and not parameter of Traction.

Open Question is how this information will be transmited in operational Phase if necessary to know it there also - if necessary than suggested new element shall be (probably) somewhere in TrainRunningTechData in TrainCompositionMessage...

Miloš Futera (SŽCZ)

For SNCF Réseau : OK with the idea.

But I agree with Maté that this element  logically belongs more to PlannedTrainTechnicalData rather than to TractionDetails.

Hi Maté,

Thanks for your answer. Yes this information is stored in TypeCode2 of element LocoTypeNumber.
But the problem is, that element TractionMode remains mandatory although it is not appropriate for these types of trains.

So my proposal was, that we should use either TractionMode or NumberOfUnits (always one of both) depending on the LocoTypeNumber (ie, regular train set or multiple unit set).

If regular trainset => TractionMode is used, describing the position of traction elements in the train
If multiple-unit set (TypeCode2 is 3,4,5) => then NumberOfUnits is used, position of loc has is pointless here, and we just want to know the number of units

Yes. However, unfortunately, not all IMs were able to publish the loco types with their 4 digit code. That is the reason that the field in PCS accepts longer alphanumeric values. For the pilot, we ensure that only "compliant ids" are used in communication, like this: 

Hi Maté,

in your added sreenshot from PCS I see element  loco type contains letters and digits. That is situation inside PCS. Does PCS ensure in communination outside via CI that element loco type number only contains digits as defined in document "taf_cat_comlete_sector.xsd"?

Kind regards Wolfgang

Hi Loic,

Doesn't the TypeCode2 store this information? Code 3,4,5 tells you that it's a multiple unit. For example, in PCS we store this information for every registered loco type, whether it's a multiple unit or not. I attached also a screenshot below. Having that, IMs and Applicants apply today several options:

1. Publish the traction with the flag that it's a multiple-unit. If the Applicant has more of this unit in the train, it adds more entries to the traction details
2. Publish the traction with the flag that it's a multiple-unit, but not only for single, also for double units. It's a common behavior of e.g. SNCF Réseau, Infrabel.

TypeCode2 elements:

0 Miscellaneous
1 Electric locomotive
2 Diesel locomotive
3 Electric multiple-unit set (high speed) [power car or trailer]
4 Electric multiple-unit set (except high speed) [power car or trailer]
5 Diesel multiple-unit set [power car or trailer]
6 Specialised trailer,
7 Electric shunting engine
8 Diesel shunting engine
9 Special vehicle

OK with naming 'TypeOfUsedEnergy (cf. comment CR151)

OK with the CR but ‘EnergyOfUsedPowerUnit’ could be a better wording.
The annotation could then be ‘information about the kind of energy used by the power unit in case of hybrid locomotive (1-electric, 2-fuel, 3-battery, 4-hydrogen)’

Wolfgang,

I'm afraid there is a misunderstanding. I mean the use of NumberOfUnits would be only for trains made of one or several autonomous units, like TGV or ICE. In these cases, the position of traction doesnt mean anything. If using TractionMode for a dual TGV for example, there might be different coding by different companies. Do you count only 2 traction units in lead position, or 1 in lead position and 1 in middle ? This makes no sense for autonomous multiple units, because 1 unit is both traction and coaches simultaneously. Therefore in such case, we think we should know the type of units (given in LocoType) + the number of units, to have a clear description of the train.