User:RailML Orga Governance

Vorlage für railML^® 3 use cases im timetable-Schema

Use case / Anwendungsfall / :

An expressive name in English; Ein aussagekräftiger Name in Deutsch;

Description / Beschreibung /

What is the application behind the use case? Which data are required? Who or which tool/application provides these data? Which data are not included (if not obvious)? Define the boundaries of the use case and the relevant data. (max. 200 words, English)

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

Which data flows (from/to the use case application) exist? Which data and process interfaces exist?

References to other data models or outside-world / Referenzen zu anderen Datenmodellen einschl. Nicht-Software-Daten /

Please note here which references to other data models come with that use case. Such references (also described as key expressions) may be one single attribute or a combination of several attributes of the respective <element>. Typical examples are

• <designator>s for a national register of stations (<ocp>s),
• <line> and/or <track> numbers, names, codes, possibly with UIC numbers,
• codes of infrastructure or interlocking elements like signals, switches, signal boxes, level crossings, interlocking routes,
• types, classes, codes of <vehicle>s,
• names or codes of <categories>,
• train numbers, codes or names,
• names of circulation plans.

Please do also think about more indirect references to the world outside of software like possibly the names of companies such as infrastructure managers.

You do normally not need to specify references which lead into the already predefined XML world such as dates (of Gregorian calendar), times (of 24 hour clock), or coordinates including heights (of a pre-defined world coordinate system) except if there are special assumptions by the use case.

Please note which references are

• mandantory
• optional, typical
• optional, seldom

for that use case or even, if applicable, which shall be avoided or explicitly not assumed.

Please note which attributes or sets of attributes must be unique within the railML^® file defined by the use case (so in spite of they do not need to be unique by the railML^® schema).

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen /

• infrastructure
• rolling stock
• interlocking
• other ..............

Please note which references are

• mandantory
• optional, typical
• optional, seldom

for that use case, from-to which <element>s the references exist (at least, typically) and if there are any references which do not use the default id-ref system of railML^®.

Characterising Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

• static (not changing)
• yearly
• regular changes
• monthly
• weekly
• daily
• realtime (seconds)

How big are the data fragments to be exchanged (complexity)?

• tiny (attribute)
• very small (element)
• small (single train run)
• big (line)
• huge (region)
• whole data set (detailed operational concept network)

Which views are represented by the data (focus)?

• Long term planning (eg. for infrastructure dimensioning)
• Mid term planning (eg. for yearly timetable disposition)
• Short term planning (eg. for trackworks)
• Real term planning (eg. for dispatching)
• Statistics
• Fare collection
• Passenger information
• ...

Which specific timetable data do you expect to receive/send (elements)?

Fill in your application-specific data structure elements, which you are using and want to see modelled in railML 3.
Please describe also structures which should be modeled in another way (so called "refactoring") in railML 3.
Attention: This is the most important part of this questionaire. Please define as detailed as possible, the length isn't limited here.

1. railML® 3 use cases im Timetable-Schema

Use case / Anwendungsfall / Scénario d’utilisation:

Passenger information at stations/Fahrgastinformation am Bahnhof

Description / Beschreibung / Description

This use case describes the exchange of data between a system for providing passenger information at a railway station and a timetable planning system. The PIS allows for display of the current schedule including information about the current state of operation such as delays, cancelation or additional trains. In order to do so the schedule as published to the passenger for the current day of operation is necessary. The completeness of this timetable information limits the accuracy of the information available to the passenger by means of the PIS. The mandatory data can be limited to the services run on the current operation day, including all stops of a train with the according arrival and departure times. Additional information for can be provided to model blocks of services (can be used to increase accuracy of forecast information), planned interconnection with other services, planned construction sites with impact on the services, etc.

Data Flows and Interfaces / Datenflüsse und Schnittstellen / Flux de données et interfaces

A PIS is a pure railML consumer.

Mandatory information imported from timetable system includes:

• <train>
• <trainPart>
• <category>
• <ocp>

Optionally imported information includes:

• <track>
• <formation>
• <annotation>/<annotationRef>
• <rostering>
• <connection> (in order to provide and manage connection information for internal or external services)
• <statistics>

If the topology is not imported from railML it is assumed that it is imported from a different source including an appropriate mapping to the ocp’s imported from railML.

Interference with other railML® schemas / Interferenz mit anderen railML®-Schemen / Interaction avec autres schemas railML®

Mandatory: infrastructure

Optionally: rolling stock

Characterizing Data / Charakterisierung der Daten / Caractérisation des données

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

yearly

regular changes

daily

How big are the data fragments to be exchanged (complexity)?

Huge - whole data set

Which views are represented by the data (focus)?

Mid term planning (eg. for yearly timetable disposition)

Short term planning (eg. for trackworks)

Passenger information

Which specific timetable data do you expect to receive/send (elements)?

Element	Mandatory	Remarks
Infrastructure/operationControlPoints/ocp	X	Used for referencing with the PIS topology
<timetable>/<timetablePeriods>/<timetablePeriod>	X
<timetable>/<operatingPeriods>/<operatingPeriod>	X
<timetable>/<categories>/<category>
<timetable>/<annotations>/<annotation>
<timetable>/<trainParts>/<trainPart>/formationTT
<timetable>/<trainParts>/<trainPart>/operatingPeriodRef	X
<timetable>/<trainParts>/<trainPart>/ocpsTT	X
<timetable>/<trainParts>/<trainPart>/ocpsTT/times	X
<timetable>/<trainParts>/<trainPart>/ocpsTT/connections
<timetable>/<trainParts>/<trainPart>/ocpsTT/connections/connection
<timetable>/<trainParts>/<trainPart>/ocpsTT/connections/connection/annotationRef
<timetable>/<trainParts>/<trainPart>/ocpsTT/statistics
<timetable>/<trainParts>/<trainPart>/ocpsTT/sectionTT/runTimes
<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription
<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription/stopTimes
<timetable>/<trainParts>/<trainPart>/ocpsTT/stopDescription/annotationRef
<timetable>/<trainParts>/<trainPart>/annotationRef
<timetable>/trains/train	X
<timetable>/trains/train/trainPartSequence	X
<timetable>/trains/train/trainPartSequence/trainPartRef	X
<timetable>/rosterings/rostering/blockParts/blockPart
<timetable>/rosterings/rostering/blocks/block
<timetable>/rosterings/rostering/blocks/block/blockPartSequence/blockPartRef

Mit Blick auf den Usecase Fahrgastinformation im Fahrzeug sollte <annotation> u. U. erweitert werden, um das Zielsystem der Sonderinformation zu bestimmen. Ausserdem sollte m. E. nach im rostering der Übergangstyp hinterlegt werden. Das hat Einfluss auf die Prognoseberechnung, sowie die berechnung von Via Zieltexten.

Reminder: geocoordinaten am ocp sollten u.U. auch den Kodierungsstandard enthalten (WGS84, CHxxx).

D R A F T - railML^® 3 use case Timetable Information

Status

13.03.15: v0.1 - First draft by Philip Wobst (HaCon)

Next Steps

• Review functional requirements with HaCon HAFAS timetable information team (P.Wobst)

Use case / Anwendungsfall / :

Timetable Information; Fahrplanauskunft;

Description / Beschreibung /

Timetable information may include a range of passenger information systems such as a journey planner and print material as well as ticketing and real-time information. This use case will focus on the definition of the minimum requirements for passenger information. The required data includes stations, timetables, service categories. Furhtermore, data regarding links among stops and interchange times can be provided if available. This data would be provided by the long term planning (LTP) or short term planning (STP) timetabling tool. For short term changes/updates the focus lies on the data relevant for passengers information only (commercial view).

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The data is provided according to the customer specific planning and subsequent publication processes. Usually fixed deadlines and timeframes exist for the typical planning horizons (please see below Which views are represented by the data (focus)?).

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen /

• infrastructure: <ocp>
• rolling stock: <formation> (?)
• interlocking: -

Characterizing Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

• yearly for LTP planning
• regular changes for STP planning
• daily for VSTP planning

How big are the data fragments to be exchanged (complexity)?

• whole data set: provide the full timetable
• full time window: provide full timetable for fixed time window (e.g. next 10 days only)
• changes for time window: provide only updated elements for a fixed time window (e.g. next 30 days)

Which views are represented by the data (focus)?

• LTP: the next yearly timetable - e.g. availability of the next yearly timetable 6 months ahead of time
• STP: short term planning changes to the current timetable - e.g. updated timetable information is provided for days +2 to +60

There is no fixed process for the exchange of data with a passenger information system. Whether or not it makes sense to identify and supply updates to a previous export file strongly depends on the capabilities of the systems involved (further discussion needed). Possible export options could be:

• Full: a full timetable is provided for a specific time window
• Update: only changes to the last export are provided for a specific time window (for the update process all files need to be handled in the correct sequence!)

Which specific timetable data do you expect to receive/send (elements)?

As a bare minimum the commercial view of a <train> can be reduced to one <trainPart> with a sequence of <ocpTT> elements with commercially relevant stops (<stopDescription> with commercial='true'). For the each stop the following data is shown:

• published times: <times> element with scope='published'
• connections: <connection> element(s) with connType='commercial'
• stop description: only <stopDescription> elements with commercial='true' will be relevant including their <stopTimes> element

In addition the following data would be useful for passenger information:

• platform
• etc.

Handling of connections for partial exports

Depending on the process in the receiving system it might be necessary to provide only a single train with all the relevant connections. However, without the connected trains the current connection element is not valid and the referenced IDs cannot be used to map the connected trains/trainParts.

Referencing platforms in the timetable

Currently the track and platform information shall be provided via the trackRef attribute linking the corrosponding element in the infrastructure. However, this requires quite a detailed infrastructure export. It should be possible to provide the commercial stations and platforms needed for the timetable export only.

Handling of cancellations, partial cancellations, extra trains

Relevant changes to existing trains need to be represented in the export file. A complete list of changes needs to be defined. This will include the following changes:

• full cancellation of a train
• partial cancellation - i.e. of a trainPart
• extra train or trainPart
• cancelled stop
• extra stop
• etc.

Discussion

• Minor changes to the <formationTT> are not necessarily relevant and could be ignored (only the category is relevant) or should the formationTT element be optional?

Terms and Expressions

• LTP = long term planning: the yearly timetable(s)
• STP = short term planning: changes to the current production timetable up to the point that changes can be published to downstream systems (passenger information, train control, train operators, etc.)

Below the this line begins the proposal for a railML^® use case

---

Use case / Anwendungsfall / :

A timetable for a competition (call for proposals) Ausschreibungsfahrplan;

Description / Beschreibung /

The use case describes a timetable which is transferred

• from an authority issuing the invitation to bid
• to any potential bidder

with the aim to describe which timetable is asked for in the competition, i. e. the amount of trains, their routes and (regular) operating days and possible any other properties of the trains such as services or minimum seating capacities.

The background behind such a data exchange with railML^® files is, especially at competitions of large production amount, it will be easier for the bidders to reproduce the timetable in their own software systems. This allows a quicker calculation e. g. of the number of vehicles necessary or, at least, the price. Time consuming and potential faulty manual transcription of the timetable shall be avoided. The usage of railML^® for such a data exchange (instead of more special file formats) shall keep this procedure transparent and non-discriminating.

The main intention of the use case is passenger traffic since the number of trains and the extent of the timetables is typically more complex than in freight traffic. But it may also be used for freight traffic.

Data Flows and Interfaces / Datenflüsse und Schnittstellen /

The use case covers a one-direction data exchange only; a possibly offered timetable (from bidder to authority) is not part of this use case.

The use case covers the exchange of the following data in general:

• <train> elements with their routes and timings (in associated <trainPart> elements),
• <ocp> elements to describe the references from the trains to the infrastructure (stations).

There are several degrees of complexity of which the use case may be used:

• with minimum infrastructure (general <ocp>s only) or all necessary infrastructure (<lines>, <track>s, gradients, speeds a. s. o.),
• with or without <vehicle>s and <formation>s,
• with or without a timetable period,
• with or without circulation plans.

The following description refers to the usage of railML^® model 2.2 for this use case since there is no version 3 in use at time of writing.

Infrastructure

From the current experience, it is typical that railML^® files of that use case contain a minimum infrastructure only. The main reason for that may be that normally the authority issuing is not the infrastructure manager. Nevertheless, general infrastructure data are quite published in a competion as a kind of “passing through” issue from the infrastructure manager(s) through the issuing authority. So it may be that they are included in the same railML^® with the timetable. With the advent of national infrastructure registers, it is likely that such registers are referred or extracted in another, say, railML^® file.

Anyway, <ocp>s must be included since without them no railML^® <timetable> file is possible. <lines> and <tracks> are included if necessary to exactly describe the train’s route in complex infrastructure situations (areas of parallel lines). More infrastructure data (gradients, speed a. s. o.) are rather a matter of the previous paragraph.

It shall be assumed that a timetable of this use case is checked by the infrastructure manager(s) in advance and therefore planned in detail.

If more infrastructure is included, its scope is macroscopic.

Timetable period

Typically there is no <timetablePeriod> for timetables of this use case. The timetable is valid not for a certain but a number of years which are not specified in the railML^® file.

The <operatingPeriod>s of the trains have regular weekdays only with no special operating days and no certain date references. The timetables are typically not planned with regard to public holidays or such; the amount of train kilometers a. s. o. is only calculated on a statistic basis (flat number of operating days, statistic year).

However, there may be a <timetablePeriod> defined for one year as a place-holder for all the years. This is common practice if seasonised trains operate, e. g. school trains or summer-only trains.

Theoretically, there may be a very long <timetablePeriod> for all the years the timetable shall be valid. Since this leads to very long bitmasks of <operatingPeriod>s with normally no additional benefit it is not common and not recommended.

<vehicle>s and <formation>s

If the supply of vehicles is component of the competition, often there are neither vehicles nor formations given with the timetable data because this is treated necessary for non-discrimination. However, for practical reasons, normally there is a master vehicle at least for run-time calculation. This is often the slowest acceptable vehicle and may be a theoretical one (a coefficient of power and mass only). It is common to publish this master vehicle with the call for tenders. If the vehicles are allocated there is no reason to exclude them from the timetable.

So, there may or may not be <rollingstock> data in the railML^® file.

Circulation plans

Typically the construction of circulation plans is up to the bidder, so no circulation plans are included. This is likely to be because neither the type (and capacity) of the vehicle(s) nor the location of the depot(s) are known in advance. On the contrary, and even if the vehicles are allocated, circulation plans are expected from the bidders to show their competence.

References to other data models or outside-world / Referenzen zu anderen Datenmodellen einschl. Nicht-Software-Daten /

• In any case, <ocp>s refer to one or more national register(s) of stations or other operational places by their <designator> elements. So, it is mandatory to use at least one <designator> with a pre-defined register. For Germany, this is currently register='RL100'.

• If <line> elements are included, it must be possible to identify the <line> elements with the lines of the corresponding infrastructure manager. This can be done directly from attributes of the <line> elements or indirectly from attributes of the <track> elements. For Germany, currently the <line>.code attribute has to contain the VzG-Streckennummer, so it must be a 4-digit integer value.

• If <track> elements are included, it must be possible to identify the <track> elements with the tracks of the corresponding infrastructure manager. This can be done by a unique attribute of the <track> elements (like code) or by a direction of the track in conjunction with the <line>s. For Germany, if <track> elements are included, also <line> elements have to be included. Each <track> element must be part of (referenced by) exactly one <line> element.

• With regard to neutral (non-discriminating) data, the <category> elements do not necessarily need to refer to actual train categories of a certain operator. They can refer to categories of the corresponding infrastructure manager if applicable - or they can be missing or even contain "phantasy" categories. For Germany, since the kind of operator can still be deduced from the DB Netz’s category codes, it is likely to have "neutralised" categories. If <category>s are used, their attribute code has to be unique.

• Since the timetable is more a virtual than an actual one, <train> elements are not necessarily to be identified externally. So, train codes nor numbers need not to be given. However, for reasons of practicability, it shall be possible to uniquely identify a train. For Germany, operational trains need to have a unique set of the attributes trainNumber, additionalTrainNumber, and scope (default railML^® rules). Commercial trains need to have a unique trainNumber (additionalTrainNumber and scope do not apply here).

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen /

• <infrastructure> (mandatory)
• <rollingstock> (optional)

<infrastructure> is referenced

• from <ocpTT>.ocpRef to <ocp>.id (mandatory),
• from <sectionTT>.lineRef to <line>.id (optional),
• from <sectionTT>.<trackRef>.ref to <track>.id (optional)
• from <trainPartSequence>.<speedProfileRef>.ref to <speedProfile>.id (optional)

<rollingstock> is referenced

• from <formationTT>.formationRef to <formation>.id (optional)
• from <rostering>.formationRef to <formation>.id (optional)
• from <rostering>.vehicleRef to <vehicle>.id (optional)

Characterising Data / Charakterisierung der Daten /

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

• static (not changing)
• in cases of error-corrections: weekly .. daily in rare cases during a short period (of submission); will probably be handled by a complete data renewal (overriding)

How big are the data fragments to be exchanged (complexity)?

• infrastructure: medium (region), macroscopic
• timetable: medium (region; several up to some hundred trains); operatingPeriod: tiny (one or none)
• rolling stock: small (none, one or a few vehicles and formations)

Which views are represented by the data (focus)?

Long term planning (starting typically 1..5 years in future with a duration of typically 3..15 years)

Which specific timetable data do you expect to receive/send (elements)?

Used elements (extract - more is allowed):

Element	Mandatory	Remarks
<infrastructure>.<tracks>.<track>.<trackTopology>.<trackBegin>.<macroscopicNode>.ocpRef <infrastructure>.<tracks>.<track>.<trackTopology>.<trackEnd>.<macroscopicNode>.ocpRef <infrastructure>.<tracks>.<track>.<trackTopology>.<crossSections>.<crossSection>.ocpRef	*1	used to define the conjunction between <track>s and <ocp>s if <track>s are included
<infrastructure>.<trackGroups>.<line>.code	*2	used to identify a line of the Infrastructure Manager(s)
<infrastructure>.<trackGroups>.<line>.infrastructureManagerRef		used to identify the Infrastructure Manager(s) at least if more than one is involved
<infrastructure>.<trackGroups>.<line>.<trackRef>.ref	*2	used to define the conjunction between <line>s and <tracks>s
<infrastructure>.<operationControlPoints>.<ocp>.<designator>.register / .entry	x	used to identify an <ocp> of the Infrastructure Manager(s)
<timetable>.<timetablePeriods>.<timetablePeriod>.startDate / .endDate
<timetable>.<timetablePeriods>.<timetablePeriod>.<holidays>.<holiday>.holidayDate
<timetable>.<operatingPeriods>.<operatingPeriod>	x
<timetable>.<operatingPeriods>.<operatingPeriod>.timetablePeriodRef / .bitMask		must be used if a <timetablePeriod> is included only
<timetable>.<operatingPeriods>.<operatingPeriod>.<operatingDay>.operatingCode	x
<timetable>.<operatingPeriods>.<operatingPeriod>.<operatingDay>.<operatingDayDeviance>.operatingCode / .holidayOffset / .ranking
<timetable>.<operatingPeriods>.<operatingPeriod>.<specialService>.type / .startDate / .endDate		can be used if a <timetablePeriod> is included only
<timetable>.<categories>.<category>.code		used to identify a train type or category of the Infrastructure Manager(s) or a virtual one
<timetable>.<trainParts>.<trainPart>	x
<timetable>.<trainParts>.<trainPart>.<formationTT>.formationRef
<timetable>.<trainParts>.<trainPart>.<formationTT>.<passengerUsage>.<places>.category / .count		may be used to define a minimum necessary seating capacity
<timetable>.<trainParts>.<trainPart>.<formationTT>.<passengerUsage>.<service>.category / .count		may be used to define a minimum acceptable service
<timetable>.<trainParts>.<trainPart>.<operatingPeriodRef>	x
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.ocpRef	x
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<times scope='scheduled' …>	x
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<times scope='scheduled'>.arrival / .departure> / .arrivalDay / .departureDay	(x)	mandatory in context as usual
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.lineRef		must be used if <line>s are included
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.<trackRef>.ref		must be used if <track>s are included
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.commercial / .stopOnRequest
<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.<stopTimes>.minimalTime	(x)	mandatory in context for ordered traffic stops
<timetable>.<trains>.<train type='operational'>	x	each <trainPart> must be covered by exactly one operational train
<timetable>.<trains>.<train type='commercial'>		used if operational trains are not sufficient to describe the timetable (especially with train coupling and sharing)
<timetable>.<trains>.<train>.trainNumber / .scope / .additionalTrainNumber
<timetable>.<trains>.<train>.<trainPartSequence>	x
<timetable>.<trains>.<train>.<trainPartSequence>.sequence	x
<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>	x
<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>.ref / .position	x

*1 mandatory if <track>s are included
*2 mandatory if <line>s are included

Additional requirements

Each <trainPart> must be covered by exactly one operational train. If commercial trains are given, each <trainPart> must be covered by exactly one commercial train.

If seating capacities or services are defined at <trainPart>s and at <formation>s or <vehicle>s, later defined values override earlier defined values in the meaning of concretising. Formations override vehicles, train parts override formations. In this special use case, the values at <trainPart>s shall be treated as minimum necessary values and the values at <formation>s or <vehicle>s as planned capacity of the master vehicle(s).

If minimum seating capacities differ for certain operating days (at the same train and route section), the corresponding train has to be split in several <trainPart>s with parallel route and disjunctive operating days. Each <trainPart> can refer to a different seating capacity. All these <trainPart>s have to be joined in the corresponding <trainPartSequence>s.

(This procedure also applies to other properties of trains and train parts. Train parts with disjunctive operating days do not have to be mixed with coupled train parts, which apply to train coupling, sharing and "strengthening". See corresponding descriptions for further information.)

Open Issues

• Usage of tTimeScope="earliest" / ="latest" instead of or additionally to ="scheduled".
• Defining (planned and/or expected) connections between the <train>s involved and also to other (external) <train>s.

Improvements for further versions

1)
To be exactly, the current railML^® does not allow a distinction between values which are minimum necessary and which are planned. There may be a difference between them especially in the use case of timtables for competitions. This applies to

• arrival / departure / run times (planned run time with a master formation vs. maximum accepable run time with any other formation)
• seating capacities (planned seating capacity with a master formation vs. minimum accepable seating capacity)
• connections

and possibly more.

2)
In the current implementation of railml^® 2.x it is not clearly defined how two <trainPart> elements in succeeding <trainPartSequence>s must be chained to model a running through service (group of vehicles). One approach is to chain all <trainPart> elements with the same key (code, name, etc.) in an order whereat the last referenced <ocp> of the current <trainPart> is the same as the first <ocp> of the following <trainPart>. (This order can already be deduced from commercial train elements.) A better modelling for this aspect is, in the author’s opinion, to use the concept of commercial trains in a different way than currently described in Wiki: Each commercial train should model exactly one sequence of <trainPart> elements. Today it may contain several "parallel" sequences of <trainPart> elements at the same time, which makes it impossible to figure out which <trainPart> elements of two succeeding <trainPartSequence>s must be linked together.

3)
The redundancy of repeated arrival and departure times of coupled <trainPart>s shall be avoided e. g. by extracting "itineraries" (refactoring).

---