Topics

Thought on JMRI prototype (Aspect) signal system implementation


Bob M.
 

This post is motivated by the pain I have gone thru to try to make AAR-1946
masts operate in a reasonable way for a given layout. I am sick and tired
of making changes to the appearance*.xml files to give "aspect mapping"
blocks that give the desired aspects for a given mast pairing. In many
cases, it seems that the distributed AAR-1946 XML file simply has incomplete
mappings defined, and making that system "work" in the particual application
has required lots of "aspectmapping" block hacks.

So, this takes me to a basic question about JMRI's current aspect signaling:
Is there a particular reason why a signaling system's "aspect mappings" are
entered in each mast's appearance file? I suspect the answer is simply that
"that's simply the way it was initially developed". Is there a reason why
the "aspectmapping" cannot be "system-generic" rather than "mast-specific"?

It seems to me that it would be possible to define in one place _all_ of the
possible indications that apply when protecting a mast with a given
indication, and allow JMRI code to determine exactly which legal indications
are actually available on the mast providing the protection, and allow JMRI
to choose the least-restrictive indication available on the mast that
applies under the applicable field conditions.

It would seem that this approach would make it far easier to develop a
functional JMRI signaling system.

Such an approach could resolve many of the user issues where their
signal-system-of-choice does not happen to generate a useful
aspect/indication because mast type "X" did not provide an aspect mapping
which is suitable for some aspect/indication found on the signal-in-advance
of mast type "Y".

(I will leave for another day the question of making use in JMRI of those
indications associated with "short braking distance".)

Regards,
Bob M.


Bob Jacobsen
 

They originally were, IIRC. But then some system came up (maybe a European route signaling one? Don’t remember exactly) where that wasn’t flexible enough.

Maybe the thing to do is to allow them to be in a single file (existing or new), while still allowing any that are found in a specific appearance file to override. Then most of the ones in the appearance files could be removed.

But I don’t see why this is a source of much difficulty, so perhaps I’m answering the wrong question. Putting them in one file (whether it’s an existing one or some new one) is only a minor improvement over “copy and paste the same contents into each file”. But if there are ' lots of "aspectmapping" block hacks’ needed, something else must be going on.

Does a single common set work?

Bob

On Jun 19, 2020, at 2:31 PM, Bob M. <jawhugrps@...> wrote:

Is there a particular reason why a signaling system's "aspect mappings" are
entered in each mast's appearance file?
--
Bob Jacobsen
@BobJacobsen


Dave Sand
 

As I see it, there are a number of issues.

The first one is prototype practices. Some prototypes probably have rules that define which mast types are compatible. This came up recently in a BR-2003 discussion. I believe the wrong preceding mast type had been used.

The second one is that as currently implemented, the <ourAspect> entry refers to one of the aspects defined in the same appearance xml file. Using a common aspect mapping file would require logic to filter out the <ourAspect> entries that are not available.

Dave Sand

----- Original message -----
From: Bob Jacobsen <@BobJacobsen>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Thought on JMRI prototype (Aspect) signal system implementation
Date: Friday, June 19, 2020 4:40 PM

They originally were, IIRC. But then some system came up (maybe a European route signaling one? Don’t remember exactly) where that wasn’t flexible enough.

Maybe the thing to do is to allow them to be in a single file (existing or new), while still allowing any that are found in a specific appearance file to override. Then most of the ones in the appearance files could be removed.

But I don’t see why this is a source of much difficulty, so perhaps I’m answering the wrong question. Putting them in one file (whether it’s an existing one or some new one) is only a minor improvement over “copy and paste the same contents into each file”. But if there are ' lots of "aspectmapping" block hacks’ needed, something else must be going on.

Does a single common set work?

Bob

On Jun 19, 2020, at 2:31 PM, Bob M. <jawhugrps@...> wrote:

Is there a particular reason why a signaling system's "aspect mappings" are
entered in each mast's appearance file?
--
Bob Jacobsen
@BobJacobsen


Bob M.
 

Dave S. wrote: ":The second one is that as currently implemented, the <ourAspect> entry refers to one of the aspects defined in the same appearance xml file. Using a common aspect mapping file would require logic to filter out the <ourAspect> entries that are not available."

As I see it, each appearance file _must_ implement a subset of the so-called "<aspect>" values as defined in the aspects.xml file. They _cannot_ (should not) implement other "<aspect>" names. As such, each appearance file defines <aspectname> values which comprise a subset of the <name> values defined for <aspect>s found in the aspects.xml file. Any appearance file may implement a set of <aspectname> values which is identically equal to the set of <name> values in the <aspects> in aspects.xml, although most appearance files represent a mast which cannot display every aspect defined in the aspects file.

It ought to be a "Simple Matter of Programming" for JMRI to find the intersection between available "aspect" names from aspects.xml and <aspectname> values from the appearance file, and define a list of aspects which are not supported by the mast. And then copy the centralized aspectmappings list and "prune away" any <ourValue> entry which is in the list of aspects not supported by the mast. This can be done at mast-type load time.

Dave S. also wrote: "Some prototypes probably have rules that define which mast types are compatible."

In the AAR-1946 signal system I've been working with, as well as another signaling system I've worked with, the prototype often implemented mast pairs which did not seem intuitively obvious. In the case of AAR-1946, it is not uncommon to find "unexpected" pairings when looking though the various drawings showing electrical schematic implementations for certain common signaling situations. And it is some of these "unexpected" pairings that I seem to be having difficulty with in JMRI. It is as if JMRI's AAR-1946 implementation as decided which pairings make sense and has ignored the "unexpected" cases. This is the type of case which has caused so much .XML rework for me.

As a simple example, a dwarf signal can be found "protecting" just about _any_ other mast type. This occurs because a dwarf may be an "entering" signal just about anywhere in signaled territory, so the dwarf really needs to be able to "protect" any other aspect available in the signaling system.

But the three AAR-1946 "low" mast appearance files define 11, 15, and 16 (respectively) "<advancedAspect>" values. Compare those counts to 21 possible aspects available in the signaling system. That comparison implies that _none_ of those dwarf signals may be properly used to protect at least some of the signal system's masts. There is _no_ dwarf definition that will protect the so-called aspects "Clear Alt", "Permissive Medium", or "Stop and Proceed Medium".

Regards,
Bob M.


Bob M.
 

I would love to understand the situation which drove to the mast-specific <aspectMapping> implementation. Anyone got any relevant history to share?

Bob J.,

In case you are proposing defining a single set of <aspectMappings> and using it as the appearancemaps in each of the signal system's appearance*.xml file: that would not work because each mast supports only a given set of aspects.

But I expect that a single common set of aspect mappings, along with some coding changes to selectively use data from that set of <aspectMappings> data, on the basis of the aspect capabilities of the given mast (or mast type), would work for the application of AAR-1946 that I am currently working with. And I expect that such an implementation would work for (most?) other US-style signaling systems.

Why is this whole thing problematic for me?

I'm working on a generic solution for AAR-1946 which assumes any mast type can be used to protect any other mast type. That system has 12 appearance files (i.e. 12 unique mast types), and 21 unique aspects available across all mast types. Since any mast can protect any other mast, and the next mast can display any of those 21 aspects, that means that each of 12 appearance files requires 21 <aspectMapping> definitions, each containing _only_ those <ourAspect> values which may be presented by the mast being defined in appearance file. That means that there ought to be a total of 252 <aspectMapping> blocks (12 mast appearance files * 21 total mappable aspects available). But there are currently only 188 defined, so I am trying to create the 64 missing <aspectMapping> blocks. And I am having to cherry-pick the <ourAspect> values to include only those aspects which are defined in the appearance file.

I haven't come up with a workable "automation" for the process, so I am struggling with making hand-edits in a correct way. This is the source of my difficulty!

And I one who tries to create a new signal system as a similar general solution must go thru the same basic process but does not have the advantage of a partially-complete set of <aspectMapping> blocks!

Net result is that I feel that all of this tedious, repetitive error-prone hand-work could be eliminated by some coding changes plus tedious manual generation of a single centralized set of aspect mappings.

For the purpose of providing "backward-compatibility" for existing signaling systems (and new ones implemented based on the same principles):

I envision that the coding changes could simply read existing mast-specific <aspectMappings> (if any) at mast-type load time. If the mast-type load resulted in an empty internal representation of the <AspectMappings>, then the code could generate the <aspectMappings> by referencing the centralized aspectMappings and pruning away any <ourAspect> values which do not apply for the mast-type.

I also envision an "override" operation capability where the signal mast appearance file only sparsely defines one or more <aspectMapping> blocks, and the centralized mappings would otherwise apply. This allows an appearance file to override the aspect mappings for one or more <advancedAspect> block(s). Perhaps the previous paragraph's functionality could simply be a degenerative case of this case's implementation for any appearance file which does not define a given <appearanceMap><advanceAspect>...</appearanceMap> block. This might be the easiest to implement, most-orthogonal, mechanism, and may have positive implications on testabilty and coverage.

Regards,
Bob M.


Bob M.
 

Dave S. wrote "Some prototypes probably have rules that define which mast types are compatible. This came up recently in a BR-2003 discussion."

Perhaps the signaling system definition for a given mast could be extended to include some "usage restriction" metadata which would allow JMRI to flag when a mast type is used in a way that is inconsistent with signaling system requirements? Perhaps this checking would be done during SML signal-pair discovery.

Regards,
Bob M.


Paul Bender
 




On Jun 19, 2020, at 9:01 PM, Bob M. <jawhugrps@...> wrote:
As a simple example, a dwarf signal can be found "protecting" just about _any_ other mast type.  This occurs because a dwarf may be an "entering" signal just about anywhere in signaled territory, so the dwarf really needs to be able to "protect" any other aspect available in the signaling system.  

Here is a question for you:  what does the railroad you are modeling call a dwarf signal?

On the Frisco, signals marked on the right of way diagrams as “dwarf” were just signals with a low mast height.  The mast height doesn’t have any impact on the indications a particular mast can display.  ( see https://www.jmri.org/xml/signals/SLSF-1973/index.shtml )

( I have been told that the choice of mast height was determined by terrain and line of sight conditions.)

Paul


Petr Šídlo
 

Bob M.
I would love to understand the situation which drove to the mast-specific <aspectMapping> implementation. Anyone got any relevant history to share?
For example ČSD Czechoslovak state railways (and his successors) https://www.jmri.org/xml/signals/SZDC-2015-zakladni/index.shtml (or DB German train https://www.jmri.org/xml/signals/DB-HV-1969/index.shtml similar situation).

different ourAspect for same advancedAspect depends on kind of signal mast
Distant signal https://www.jmri.org/xml/signals/SZDC-2015-zakladni/appearance-entry_distant.xml
Distant signals repeater https://www.jmri.org/xml/signals/SZDC-2015-zakladni/appearance-entry_distant_repeater.xml





--
Petr Šídlo
Czech Republic
https://sites.google.com/site/sidloweb/


Bob M.
 

Paul,

It is my understanding that the AAR defined a "low" signal (i.e. dwarf) to be any signal that is below the level of the cab of a passing train, and a "high" signal to be any signal where as any signal where the aspect-indicating devices are all above the level of the cab.

It is my understanding that a signal being "low" versus being "high" related ONLY to interpretation versus rule. The signaling rules may be set up so that a given _aspect_ on a low signal gives an _indication_ that is different from the _indication_ associated with a high signal when that high signal presents the same _aspect_. For example, under AAR-1946, a single green lamp on a high absolute signal indicates "Clear", but on a low absolute signal indicates "Slow Clear".

Note that some railroads defined their signal rules so that a given aspect on a high signal had an indication that was _identical_ to the indicaiton of a comparable low signaling presenting that same aspect. (I am a volunteer for a local museum railroad where this is the case.)

And, with respect to "low" versus "high": I have seen cases where a dwarf signal was mounted on a short mast so that it was visible to an approaching train over a "hump" in the topography. Because the mast was VERY short, the signal was just below cab height, and therefore qualified as a low signal and needed to be interpreted as a dwarf. One example can be found at http://rrsignalpix.com/grsfalenox.html. I've seen examples where the "mast" below the dwarf was perhaps 4 or 5 feet tall!

Regards,
Bob M.


Bob M.
 

Petr,

I have not spent any great time studying either of the signal systems you pointed to. I find that the non-english characters make it difficult to truely understand the signaling system, even though much of the information is in English. I will have to create an english-only equivalent of the signal set in order to try to understand the signal system. (This is not a high-priority for me at the moment.)

Can you point me to two specific signal mast types, and a single "advancedAspect" where the conflict occurs between aspectMapping sets?

Does the problem resolve around the "train run into an already partly occupied platform" indications? Such indications imply "permissive" occupancy of a block by more than one train. Deciding when it is acceptable to allow permissive occupancy is not necessarily obvious or easy. For example, is the platform provided with more than one occupancy detection block, so that the signal system may know that the there is a train, and that it has pulled far-enough ahead that another stopping spot is available for another train?

(In US prototype practice, signaling for high-frequency passenger operations can be remarkably different from signaling for low- and medium-density freight operations. This is exemplified by differing practices for subway systems than for freight railroads. Perhaps it would be helpful if I studied-up on US subway signaling practices...)

Regards,
Bob M.


Petr Šídlo
 

The Czechoslovak signaling system is intended primarily for Czech and Slovak users. Therefore, the aspects are named in Czech.

If the Entry signal is located in an unsuitable place (curve, tunnel, rock, ...) and it is difficult to see it, then a Distant signal repeater is inserted between the Distant signal mast and the Entry signal mast.

A similar, but a bit more complicated, situation is in stations where a Exit signal is precedes with
Intermediate signals https://www.jmri.org/xml/signals/SZDC-2015-zakladni/appearance-intermediate.xml

General rule - if the next signal mast (advanced) is away from the current signal mast (our) by a distance shorter than the prescribed braking distance, then this dangerous situation must be signaled by an additional white light.

We also know the permissive Stop aspect, but we solve it in a different way.

--
Petr Šídlo
Czech Republic
https://sites.google.com/site/sidloweb/


Bob M.
 

Petr,

I cannot afford to spend time digging thru elevenSZDC-2015-zakladni signal mast definitions, extract the aspect names and the aspect mappings applicable to each, figure out which masts apply in which sequences, and then dig thru the intersection of aspect mappings for each legal mast-type pairing, all to try to find the mysterious "reason why mast-based aspectMappings" is required. Unless you provide _specific_ mast pairs and conditions which result in conflicting aspect mappings, I am not going to be able to truely understand why "aspectMappings" must be mast-based for this signal system.

Note that the proposals I have made would allow such a pre-existing signal system to be left unchanged and they would work just the same as they do now. And the changes I propopose would allow such a pre-existing signal system to be reworked (by a person with appropriate understanding of the signal system) to make use of a centralized aspect mapping where appropriate, with mast-specific "overrides" where appropriate. Because of these capabilities of my proposed mechanisms, I do not see a _need_ for me to truely understand why the previous decisions were made.

With respect to "entry" and "distant signal repeater" masts: Given 3 signal masts - an "Entry" signal, a "distant signal repeater" protecting the entry signal, and some other mast that exists "in the rear" of the distant signal repeater, does that mast farthest from the "Entry" signal depend on the indication given by the "distant signal repeater" or does it depend on the indication given by the "Entry" signal?

The "additional white light" seems to indicate the equivalent of the US concept called "short braking distance". In the US, where distances between signal masts is less than the prescribed braking distance, "extra" aspects are required to give additional information to the train crew, or, the signal system must implement "doubled" signal indications, such as two or more consecutive masts indicating "Approach" before a mast which indicates "Stop". JMRI does not have any good mechanisms for implementing "short braking distance" indications. Some sort of support in JMRI for intelligent "short braking distance" signaling is something I would like to addressed at some time in the future. Our models tend to compress distances greatly, and thus "short braking distances" between signals tend to be more common than "prescribed" braking distances.

Regards,
Bob M.


Balazs Racz
 

Bob M,

Dick Bronson has created a product line for implementing prototypical aspect-based signaling using LCC boards and no computer. Since those are all embedded devices, creating large translation tables was not a possible option. To overcome this, Dick studied how the prototype signaling system was designed, and found that there is a concept that allows decomposing the N*N table into two much smaller N*k tables. So in addition to being more prototypical in how we model the signaling system (in that we model the design decisions of the prototype) it allows much simpler expressions of the signaling logic.

The concept is track circuits, and it is the communication line that the prototype used between the signals. The signaling logic puts a coded message onto the track, to be received by the preceding signaling logic, in order for that preceding signaling logic to understand what lies ahead and correctly compute the aspect of that preceding signal mast.
The codes were standardized, and even in cases where there were dozens of different aspects to show, the track circuit only had 6 or 7 different codes that it could transmit. The signaling logic therefore did not have access to what aspect lies ahead, only a projection of that down to the essential information -- the track circuit code.

Today we are trying to express signaling logic this way:
aspect ahead + local conditions [e.g. turnouts, occupancy] => aspect to show.

Instead the prototype did the following:
track circuit code received  + local conditions => aspect to show + track circuit code to emit.

The standardization of track circuit codes allowed any signal box to be compatible with any other signal box ahead and behind, which enables performing the safety certification of the signal box logic only once, which has huge cost advantages.
Dick wrote a bit about this in his product manual here: http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf sections 9, 9.3 and 9.4.

A very similar concept exists in the Siemens SpDr line of control point logic, which had several versions from 55 to 67, and is extremely widespread in many European countries even to the present date. There the control logic is pre-manufactured for each track element (e.g. a turnout or an entry advanced signal), and the track elements connect to each other with a standardized cable. The information of an arbitrary complexity of forward looking track configuration and state (including aspects) is projected down to the standard indications that come through that fixed connector. A turnout would have three connectors, a signal mast placed on open track would have two. Unfortunately I've never seen any technical description of how these connectors are laid out and what logical information they represent.

The bottom line is that we should allow for introducing a concept of projected information ("code") that is sent between masts, and refactoring the signaling descriptions into this form:
code received  + local conditions => aspect to show + code to emit.
There is no guarantee that this will work for every signal system, but it should be possible for at least the prototypes that used track circuits and those European Spurplanstellwerke. If we do this, there is a good chance we can get to prototypical behavior with much less work for those signaling systems.

hth
Balazs

 


On Sat, Jun 20, 2020 at 10:53 PM Bob M. <jawhugrps@...> wrote:
Petr,

I cannot afford to spend time digging thru elevenSZDC-2015-zakladni signal mast definitions, extract the aspect names and the aspect mappings applicable to each, figure out which masts apply in which sequences, and then dig thru the intersection of aspect mappings for each legal mast-type pairing, all to try to find the mysterious "reason why mast-based aspectMappings" is required.  Unless you provide _specific_ mast pairs and conditions which result in conflicting aspect mappings, I am not going to be able to truely understand why "aspectMappings" must be mast-based for this signal system.

Note that the proposals I have made would allow such a pre-existing signal system to be left unchanged and they would work just the same as they do now.  And the changes I propopose would allow such a pre-existing signal system to be reworked (by a person with appropriate understanding of the signal system) to make use of a centralized aspect mapping where appropriate, with mast-specific "overrides" where appropriate.  Because of these capabilities of my proposed mechanisms, I do not see a _need_ for me to truely understand why the previous decisions were made.

With respect to "entry" and "distant signal repeater" masts: Given 3 signal masts - an "Entry" signal, a "distant signal repeater" protecting the entry signal, and some other mast that exists "in the rear" of the distant signal repeater, does that mast farthest from the "Entry" signal depend on the indication given by the "distant signal repeater" or does it depend on the indication given by the "Entry" signal?

The "additional white light" seems to indicate the equivalent of the US concept called "short braking distance".  In the US, where distances between signal masts is less than the prescribed braking distance, "extra" aspects are required to give additional information to the train crew, or, the signal system must implement "doubled" signal indications, such as two or more consecutive masts indicating "Approach" before a mast which indicates "Stop".  JMRI does not have any good mechanisms for implementing "short braking distance" indications.  Some sort of support in JMRI for intelligent "short braking distance" signaling is something I would like to addressed at some time in the future.  Our models tend to compress distances greatly, and thus "short braking distances" between signals tend to be more common than "prescribed" braking distances.

Regards,
Bob M.






Bob Jacobsen
 

To summarize:

1) BobM has been spending time keeping the tables in multiple appearance files within a single signal system consistent.

2) Petr points out that there are signal systems that do require mast-type-specifict considerations

3) Having a local-default table that is the first choice for the system, allowing override by a table within an appearance file if needed, seems to be a possible improvement to how we do things.

Anybody want to code that?

If I were doing it, I’d put the common table in a separate per-system file, but whoever codes it gets to pick.


4) Balazs points out that there might be more efficient ways to code this than NxN (N aspects, each of which is related to N aspects). A central file is likely to have more cases, because it has to cover _all_ aspects of the system instead of just those that can be shown by a single mast. So perhaps a still-general simplification would be a good addition. But that seems separate from solving BobM’s problem with duplication and consistency.

Bob (J)


Dave Sand
 

Balazs,

The aspectMappings table defines the "track circuits" in SML.  The track circuit "code" is the advancedAspect.

Is there a common set of track circuit codes -or- does each railroad have their own -or- is it a combination of common and railroad specific?

Adding formal support to JMRI for track circuits would not be very hard but it seems redundant.  The mast aspects would map to a circuit code and the circuitCodeMappings table in the appearance xml file would map the advancedCircuitCode to a local aspect based on the local conditions.

Dave Sand



----- Original message -----
From: Balazs Racz <balazs.racz@...>
Subject: Re: [jmri-developers] Thought on JMRI prototype (Aspect) signal system implementation
Date: Sunday, June 21, 2020 6:15 AM

Bob M,

Dick Bronson has created a product line for implementing prototypical aspect-based signaling using LCC boards and no computer. Since those are all embedded devices, creating large translation tables was not a possible option. To overcome this, Dick studied how the prototype signaling system was designed, and found that there is a concept that allows decomposing the N*N table into two much smaller N*k tables. So in addition to being more prototypical in how we model the signaling system (in that we model the design decisions of the prototype) it allows much simpler expressions of the signaling logic.

The concept is track circuits, and it is the communication line that the prototype used between the signals. The signaling logic puts a coded message onto the track, to be received by the preceding signaling logic, in order for that preceding signaling logic to understand what lies ahead and correctly compute the aspect of that preceding signal mast.
The codes were standardized, and even in cases where there were dozens of different aspects to show, the track circuit only had 6 or 7 different codes that it could transmit. The signaling logic therefore did not have access to what aspect lies ahead, only a projection of that down to the essential information -- the track circuit code.

Today we are trying to express signaling logic this way:
aspect ahead + local conditions [e.g. turnouts, occupancy] => aspect to show.

Instead the prototype did the following:
track circuit code received  + local conditions => aspect to show + track circuit code to emit.

The standardization of track circuit codes allowed any signal box to be compatible with any other signal box ahead and behind, which enables performing the safety certification of the signal box logic only once, which has huge cost advantages.
Dick wrote a bit about this in his product manual here: http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf sections 9, 9.3 and 9.4.

A very similar concept exists in the Siemens SpDr line of control point logic, which had several versions from 55 to 67, and is extremely widespread in many European countries even to the present date. There the control logic is pre-manufactured for each track element (e.g. a turnout or an entry advanced signal), and the track elements connect to each other with a standardized cable. The information of an arbitrary complexity of forward looking track configuration and state (including aspects) is projected down to the standard indications that come through that fixed connector. A turnout would have three connectors, a signal mast placed on open track would have two. Unfortunately I've never seen any technical description of how these connectors are laid out and what logical information they represent.

The bottom line is that we should allow for introducing a concept of projected information ("code") that is sent between masts, and refactoring the signaling descriptions into this form:
code received  + local conditions => aspect to show + code to emit.

There is no guarantee that this will work for every signal system, but it should be possible for at least the prototypes that used track circuits and those European Spurplanstellwerke. If we do this, there is a good chance we can get to prototypical behavior with much less work for those signaling systems.

hth
Balazs

 


On Sat, Jun 20, 2020 at 10:53 PM Bob M. <jawhugrps@...> wrote:
Petr,

I cannot afford to spend time digging thru elevenSZDC-2015-zakladni signal mast definitions, extract the aspect names and the aspect mappings applicable to each, figure out which masts apply in which sequences, and then dig thru the intersection of aspect mappings for each legal mast-type pairing, all to try to find the mysterious "reason why mast-based aspectMappings" is required.  Unless you provide _specific_ mast pairs and conditions which result in conflicting aspect mappings, I am not going to be able to truely understand why "aspectMappings" must be mast-based for this signal system.

Note that the proposals I have made would allow such a pre-existing signal system to be left unchanged and they would work just the same as they do now.  And the changes I propopose would allow such a pre-existing signal system to be reworked (by a person with appropriate understanding of the signal system) to make use of a centralized aspect mapping where appropriate, with mast-specific "overrides" where appropriate.  Because of these capabilities of my proposed mechanisms, I do not see a _need_ for me to truely understand why the previous decisions were made.

With respect to "entry" and "distant signal repeater" masts: Given 3 signal masts - an "Entry" signal, a "distant signal repeater" protecting the entry signal, and some other mast that exists "in the rear" of the distant signal repeater, does that mast farthest from the "Entry" signal depend on the indication given by the "distant signal repeater" or does it depend on the indication given by the "Entry" signal?

The "additional white light" seems to indicate the equivalent of the US concept called "short braking distance".  In the US, where distances between signal masts is less than the prescribed braking distance, "extra" aspects are required to give additional information to the train crew, or, the signal system must implement "doubled" signal indications, such as two or more consecutive masts indicating "Approach" before a mast which indicates "Stop".  JMRI does not have any good mechanisms for implementing "short braking distance" indications.  Some sort of support in JMRI for intelligent "short braking distance" signaling is something I would like to addressed at some time in the future.  Our models tend to compress distances greatly, and thus "short braking distances" between signals tend to be more common than "prescribed" braking distances.

Regards,
Bob M.







dick bronson
 

Dave,

There are others that obviously understand this concept better than I do, but the various manufacturers seem to have used similar if not the same concepts. The actual codes used don't seem to matter as much as the concept of indicating what the train is expected to be doing as it arrives at the next signal. In many systems it is these same codes traveling over the rails that tell cab signals what to display. Obviously the codes are no longer useful to the previous (just passed) signal because they got shorted out by the train as it entered the block, but they happen to be exactly what the cab signals need in order to determine what they should display. Because they are essentially shorted out by the first loco axle, a coil placed in front of that axle is able to read the coded current in the axle, and be used appropriately.

I cover this a bit more in the manual at http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf section 9.3. If you look at the table 5-1 which was taken from an image of the actual hardware's label, you will see the term 'Aspect' but if you analyze it a bit you will see that the codes are actually indicating speeds. (with code 5 being Absolute Stop)

Dick :)

On 6/21/2020 12:16 PM, Dave Sand wrote:
Balazs,

The aspectMappings table defines the "track circuits" in SML.  The track circuit "code" is the advancedAspect.

Is there a common set of track circuit codes -or- does each railroad have their own -or- is it a combination of common and railroad specific?

Adding formal support to JMRI for track circuits would not be very hard but it seems redundant.  The mast aspects would map to a circuit code and the circuitCodeMappings table in the appearance xml file would map the advancedCircuitCode to a local aspect based on the local conditions.

Dave Sand



----- Original message -----
From: Balazs Racz <balazs.racz@...>
Subject: Re: [jmri-developers] Thought on JMRI prototype (Aspect) signal system implementation
Date: Sunday, June 21, 2020 6:15 AM

Bob M,

Dick Bronson has created a product line for implementing prototypical aspect-based signaling using LCC boards and no computer. Since those are all embedded devices, creating large translation tables was not a possible option. To overcome this, Dick studied how the prototype signaling system was designed, and found that there is a concept that allows decomposing the N*N table into two much smaller N*k tables. So in addition to being more prototypical in how we model the signaling system (in that we model the design decisions of the prototype) it allows much simpler expressions of the signaling logic.

The concept is track circuits, and it is the communication line that the prototype used between the signals. The signaling logic puts a coded message onto the track, to be received by the preceding signaling logic, in order for that preceding signaling logic to understand what lies ahead and correctly compute the aspect of that preceding signal mast.
The codes were standardized, and even in cases where there were dozens of different aspects to show, the track circuit only had 6 or 7 different codes that it could transmit. The signaling logic therefore did not have access to what aspect lies ahead, only a projection of that down to the essential information -- the track circuit code.

Today we are trying to express signaling logic this way:
aspect ahead + local conditions [e.g. turnouts, occupancy] => aspect to show.

Instead the prototype did the following:
track circuit code received  + local conditions => aspect to show + track circuit code to emit.

The standardization of track circuit codes allowed any signal box to be compatible with any other signal box ahead and behind, which enables performing the safety certification of the signal box logic only once, which has huge cost advantages.
Dick wrote a bit about this in his product manual here: http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf sections 9, 9.3 and 9.4.

A very similar concept exists in the Siemens SpDr line of control point logic, which had several versions from 55 to 67, and is extremely widespread in many European countries even to the present date. There the control logic is pre-manufactured for each track element (e.g. a turnout or an entry advanced signal), and the track elements connect to each other with a standardized cable. The information of an arbitrary complexity of forward looking track configuration and state (including aspects) is projected down to the standard indications that come through that fixed connector. A turnout would have three connectors, a signal mast placed on open track would have two. Unfortunately I've never seen any technical description of how these connectors are laid out and what logical information they represent.

The bottom line is that we should allow for introducing a concept of projected information ("code") that is sent between masts, and refactoring the signaling descriptions into this form:
code received  + local conditions => aspect to show + code to emit.

There is no guarantee that this will work for every signal system, but it should be possible for at least the prototypes that used track circuits and those European Spurplanstellwerke. If we do this, there is a good chance we can get to prototypical behavior with much less work for those signaling systems.

hth
Balazs

 


On Sat, Jun 20, 2020 at 10:53 PM Bob M. <jawhugrps@...> wrote:
Petr,

I cannot afford to spend time digging thru elevenSZDC-2015-zakladni signal mast definitions, extract the aspect names and the aspect mappings applicable to each, figure out which masts apply in which sequences, and then dig thru the intersection of aspect mappings for each legal mast-type pairing, all to try to find the mysterious "reason why mast-based aspectMappings" is required.  Unless you provide _specific_ mast pairs and conditions which result in conflicting aspect mappings, I am not going to be able to truely understand why "aspectMappings" must be mast-based for this signal system.

Note that the proposals I have made would allow such a pre-existing signal system to be left unchanged and they would work just the same as they do now.  And the changes I propopose would allow such a pre-existing signal system to be reworked (by a person with appropriate understanding of the signal system) to make use of a centralized aspect mapping where appropriate, with mast-specific "overrides" where appropriate.  Because of these capabilities of my proposed mechanisms, I do not see a _need_ for me to truely understand why the previous decisions were made.

With respect to "entry" and "distant signal repeater" masts: Given 3 signal masts - an "Entry" signal, a "distant signal repeater" protecting the entry signal, and some other mast that exists "in the rear" of the distant signal repeater, does that mast farthest from the "Entry" signal depend on the indication given by the "distant signal repeater" or does it depend on the indication given by the "Entry" signal?

The "additional white light" seems to indicate the equivalent of the US concept called "short braking distance".  In the US, where distances between signal masts is less than the prescribed braking distance, "extra" aspects are required to give additional information to the train crew, or, the signal system must implement "doubled" signal indications, such as two or more consecutive masts indicating "Approach" before a mast which indicates "Stop".  JMRI does not have any good mechanisms for implementing "short braking distance" indications.  Some sort of support in JMRI for intelligent "short braking distance" signaling is something I would like to addressed at some time in the future.  Our models tend to compress distances greatly, and thus "short braking distances" between signals tend to be more common than "prescribed" braking distances.

Regards,
Bob M.







wombat_rrnut
 

Dick:

 

In reading all of this, I’ve missed something on the prototype that won’t probably matter on the CAN bus, since

everything is connected to it.

 

Two possibilities (or more?):

At an O.S. section, there are two “track circuits” connected via the switch to the O.S. section.  I’ll have to assume that

each of those track circuits (say Main, Siding) each must communicate with the O.S. section, so there “should” be a

unique ID for each Main / Siding, so the double headed signal on the other side can display appropriate speed (or route in my case) information.

OR

The physical track switch ONLY allows one of the Main / Siding to communicate at one

time to the O.S. section to set the double headed signal (typical) which approaches the switch from the other direction.

Or is there another mechanism?

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of dick bronson via groups.io
Sent: Sunday, June 21, 2020 3:30 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Thought on JMRI prototype (Aspect) signal system implementation

 

Dave,

There are others that obviously understand this concept better than I do, but the various manufacturers seem to have used similar if not the same concepts. The actual codes used don't seem to matter as much as the concept of indicating what the train is expected to be doing as it arrives at the next signal. In many systems it is these same codes traveling over the rails that tell cab signals what to display. Obviously the codes are no longer useful to the previous (just passed) signal because they got shorted out by the train as it entered the block, but they happen to be exactly what the cab signals need in order to determine what they should display. Because they are essentially shorted out by the first loco axle, a coil placed in front of that axle is able to read the coded current in the axle, and be used appropriately.

I cover this a bit more in the manual at http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf section 9.3. If you look at the table 5-1 which was taken from an image of the actual hardware's label, you will see the term 'Aspect' but if you analyze it a bit you will see that the codes are actually indicating speeds. (with code 5 being Absolute Stop)

Dick :)

On 6/21/2020 12:16 PM, Dave Sand wrote:

Balazs,

 

The aspectMappings table defines the "track circuits" in SML.  The track circuit "code" is the advancedAspect.

 

Is there a common set of track circuit codes -or- does each railroad have their own -or- is it a combination of common and railroad specific?

 

Adding formal support to JMRI for track circuits would not be very hard but it seems redundant.  The mast aspects would map to a circuit code and the circuitCodeMappings table in the appearance xml file would map the advancedCircuitCode to a local aspect based on the local conditions.

 

Dave Sand

 

 

 

----- Original message -----

From: Balazs Racz <balazs.racz@...>

Subject: Re: [jmri-developers] Thought on JMRI prototype (Aspect) signal system implementation

Date: Sunday, June 21, 2020 6:15 AM

 

Bob M,

 

Dick Bronson has created a product line for implementing prototypical aspect-based signaling using LCC boards and no computer. Since those are all embedded devices, creating large translation tables was not a possible option. To overcome this, Dick studied how the prototype signaling system was designed, and found that there is a concept that allows decomposing the N*N table into two much smaller N*k tables. So in addition to being more prototypical in how we model the signaling system (in that we model the design decisions of the prototype) it allows much simpler expressions of the signaling logic.

 

The concept is track circuits, and it is the communication line that the prototype used between the signals. The signaling logic puts a coded message onto the track, to be received by the preceding signaling logic, in order for that preceding signaling logic to understand what lies ahead and correctly compute the aspect of that preceding signal mast.

The codes were standardized, and even in cases where there were dozens of different aspects to show, the track circuit only had 6 or 7 different codes that it could transmit. The signaling logic therefore did not have access to what aspect lies ahead, only a projection of that down to the essential information -- the track circuit code.

 

Today we are trying to express signaling logic this way:

aspect ahead + local conditions [e.g. turnouts, occupancy] => aspect to show.

 

Instead the prototype did the following:

track circuit code received  + local conditions => aspect to show + track circuit code to emit.

 

The standardization of track circuit codes allowed any signal box to be compatible with any other signal box ahead and behind, which enables performing the safety certification of the signal box logic only once, which has huge cost advantages.

Dick wrote a bit about this in his product manual here: http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf sections 9, 9.3 and 9.4.

 

A very similar concept exists in the Siemens SpDr line of control point logic, which had several versions from 55 to 67, and is extremely widespread in many European countries even to the present date. There the control logic is pre-manufactured for each track element (e.g. a turnout or an entry advanced signal), and the track elements connect to each other with a standardized cable. The information of an arbitrary complexity of forward looking track configuration and state (including aspects) is projected down to the standard indications that come through that fixed connector. A turnout would have three connectors, a signal mast placed on open track would have two. Unfortunately I've never seen any technical description of how these connectors are laid out and what logical information they represent.

 

The bottom line is that we should allow for introducing a concept of projected information ("code") that is sent between masts, and refactoring the signaling descriptions into this form:

code received  + local conditions => aspect to show + code to emit.

 

There is no guarantee that this will work for every signal system, but it should be possible for at least the prototypes that used track circuits and those European Spurplanstellwerke. If we do this, there is a good chance we can get to prototypical behavior with much less work for those signaling systems.

 

hth

Balazs

 

 

 

 

On Sat, Jun 20, 2020 at 10:53 PM Bob M. <jawhugrps@...> wrote:

Petr,

 

I cannot afford to spend time digging thru elevenSZDC-2015-zakladni signal mast definitions, extract the aspect names and the aspect mappings applicable to each, figure out which masts apply in which sequences, and then dig thru the intersection of aspect mappings for each legal mast-type pairing, all to try to find the mysterious "reason why mast-based aspectMappings" is required.  Unless you provide _specific_ mast pairs and conditions which result in conflicting aspect mappings, I am not going to be able to truely understand why "aspectMappings" must be mast-based for this signal system.

 

Note that the proposals I have made would allow such a pre-existing signal system to be left unchanged and they would work just the same as they do now.  And the changes I propopose would allow such a pre-existing signal system to be reworked (by a person with appropriate understanding of the signal system) to make use of a centralized aspect mapping where appropriate, with mast-specific "overrides" where appropriate.  Because of these capabilities of my proposed mechanisms, I do not see a _need_ for me to truely understand why the previous decisions were made.

 

With respect to "entry" and "distant signal repeater" masts: Given 3 signal masts - an "Entry" signal, a "distant signal repeater" protecting the entry signal, and some other mast that exists "in the rear" of the distant signal repeater, does that mast farthest from the "Entry" signal depend on the indication given by the "distant signal repeater" or does it depend on the indication given by the "Entry" signal?

 

The "additional white light" seems to indicate the equivalent of the US concept called "short braking distance".  In the US, where distances between signal masts is less than the prescribed braking distance, "extra" aspects are required to give additional information to the train crew, or, the signal system must implement "doubled" signal indications, such as two or more consecutive masts indicating "Approach" before a mast which indicates "Stop".  JMRI does not have any good mechanisms for implementing "short braking distance" indications.  Some sort of support in JMRI for intelligent "short braking distance" signaling is something I would like to addressed at some time in the future.  Our models tend to compress distances greatly, and thus "short braking distances" between signals tend to be more common than "prescribed" braking distances.

 

Regards,

Bob M.

 

 

 

 

 

 


dick bronson
 

Greg,

On the prototype it is each block that has a pair of units connected to it, one at each end. They both alternate between transmit and receive so the same section of track sends different data in each direction on alternating cycles. Each end of the hardware has a pair of terminal blocks with each of the inputs/outputs available to the rest of the logic. This means that in spite of having specific names, each 'code' output can actually be used as required by the individual signal engineer.

The OS equipment rack at a control point may include two, three, or even more track circuit cards, depending on how many blocks are involved. If I remember right some cards even had 2 track circuits per card. Different coding systems of course required different cards, even from the same company. The logic of how this information is used is separate from the track circuit cards.

Dick :)

On 6/21/2020 7:57 PM, wombat_rrnut wrote:

Dick:

 

In reading all of this, I’ve missed something on the prototype that won’t probably matter on the CAN bus, since

everything is connected to it.

 

Two possibilities (or more?):

At an O.S. section, there are two “track circuits” connected via the switch to the O.S. section.  I’ll have to assume that

each of those track circuits (say Main, Siding) each must communicate with the O.S. section, so there “should” be a

unique ID for each Main / Siding, so the double headed signal on the other side can display appropriate speed (or route in my case) information.

OR

The physical track switch ONLY allows one of the Main / Siding to communicate at one

time to the O.S. section to set the double headed signal (typical) which approaches the switch from the other direction.

Or is there another mechanism?

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of dick bronson via groups.io
Sent: Sunday, June 21, 2020 3:30 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Thought on JMRI prototype (Aspect) signal system implementation

 

Dave,

There are others that obviously understand this concept better than I do, but the various manufacturers seem to have used similar if not the same concepts. The actual codes used don't seem to matter as much as the concept of indicating what the train is expected to be doing as it arrives at the next signal. In many systems it is these same codes traveling over the rails that tell cab signals what to display. Obviously the codes are no longer useful to the previous (just passed) signal because they got shorted out by the train as it entered the block, but they happen to be exactly what the cab signals need in order to determine what they should display. Because they are essentially shorted out by the first loco axle, a coil placed in front of that axle is able to read the coded current in the axle, and be used appropriately.

I cover this a bit more in the manual at http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf section 9.3. If you look at the table 5-1 which was taken from an image of the actual hardware's label, you will see the term 'Aspect' but if you analyze it a bit you will see that the codes are actually indicating speeds. (with code 5 being Absolute Stop)

Dick :)

On 6/21/2020 12:16 PM, Dave Sand wrote:

Balazs,

 

The aspectMappings table defines the "track circuits" in SML.  The track circuit "code" is the advancedAspect.

 

Is there a common set of track circuit codes -or- does each railroad have their own -or- is it a combination of common and railroad specific?

 

Adding formal support to JMRI for track circuits would not be very hard but it seems redundant.  The mast aspects would map to a circuit code and the circuitCodeMappings table in the appearance xml file would map the advancedCircuitCode to a local aspect based on the local conditions.

 

Dave Sand

 

 

 

----- Original message -----

From: Balazs Racz <balazs.racz@...>

Subject: Re: [jmri-developers] Thought on JMRI prototype (Aspect) signal system implementation

Date: Sunday, June 21, 2020 6:15 AM

 

Bob M,

 

Dick Bronson has created a product line for implementing prototypical aspect-based signaling using LCC boards and no computer. Since those are all embedded devices, creating large translation tables was not a possible option. To overcome this, Dick studied how the prototype signaling system was designed, and found that there is a concept that allows decomposing the N*N table into two much smaller N*k tables. So in addition to being more prototypical in how we model the signaling system (in that we model the design decisions of the prototype) it allows much simpler expressions of the signaling logic.

 

The concept is track circuits, and it is the communication line that the prototype used between the signals. The signaling logic puts a coded message onto the track, to be received by the preceding signaling logic, in order for that preceding signaling logic to understand what lies ahead and correctly compute the aspect of that preceding signal mast.

The codes were standardized, and even in cases where there were dozens of different aspects to show, the track circuit only had 6 or 7 different codes that it could transmit. The signaling logic therefore did not have access to what aspect lies ahead, only a projection of that down to the essential information -- the track circuit code.

 

Today we are trying to express signaling logic this way:

aspect ahead + local conditions [e.g. turnouts, occupancy] => aspect to show.

 

Instead the prototype did the following:

track circuit code received  + local conditions => aspect to show + track circuit code to emit.

 

The standardization of track circuit codes allowed any signal box to be compatible with any other signal box ahead and behind, which enables performing the safety certification of the signal box logic only once, which has huge cost advantages.

Dick wrote a bit about this in his product manual here: http://www.rr-cirkits.com/manuals/SignalLCC-manual-c.pdf sections 9, 9.3 and 9.4.

 

A very similar concept exists in the Siemens SpDr line of control point logic, which had several versions from 55 to 67, and is extremely widespread in many European countries even to the present date. There the control logic is pre-manufactured for each track element (e.g. a turnout or an entry advanced signal), and the track elements connect to each other with a standardized cable. The information of an arbitrary complexity of forward looking track configuration and state (including aspects) is projected down to the standard indications that come through that fixed connector. A turnout would have three connectors, a signal mast placed on open track would have two. Unfortunately I've never seen any technical description of how these connectors are laid out and what logical information they represent.

 

The bottom line is that we should allow for introducing a concept of projected information ("code") that is sent between masts, and refactoring the signaling descriptions into this form:

code received  + local conditions => aspect to show + code to emit.

 

There is no guarantee that this will work for every signal system, but it should be possible for at least the prototypes that used track circuits and those European Spurplanstellwerke. If we do this, there is a good chance we can get to prototypical behavior with much less work for those signaling systems.

 

hth

Balazs

 

 

 

 

On Sat, Jun 20, 2020 at 10:53 PM Bob M. <jawhugrps@...> wrote:

Petr,

 

I cannot afford to spend time digging thru elevenSZDC-2015-zakladni signal mast definitions, extract the aspect names and the aspect mappings applicable to each, figure out which masts apply in which sequences, and then dig thru the intersection of aspect mappings for each legal mast-type pairing, all to try to find the mysterious "reason why mast-based aspectMappings" is required.  Unless you provide _specific_ mast pairs and conditions which result in conflicting aspect mappings, I am not going to be able to truely understand why "aspectMappings" must be mast-based for this signal system.

 

Note that the proposals I have made would allow such a pre-existing signal system to be left unchanged and they would work just the same as they do now.  And the changes I propopose would allow such a pre-existing signal system to be reworked (by a person with appropriate understanding of the signal system) to make use of a centralized aspect mapping where appropriate, with mast-specific "overrides" where appropriate.  Because of these capabilities of my proposed mechanisms, I do not see a _need_ for me to truely understand why the previous decisions were made.

 

With respect to "entry" and "distant signal repeater" masts: Given 3 signal masts - an "Entry" signal, a "distant signal repeater" protecting the entry signal, and some other mast that exists "in the rear" of the distant signal repeater, does that mast farthest from the "Entry" signal depend on the indication given by the "distant signal repeater" or does it depend on the indication given by the "Entry" signal?

 

The "additional white light" seems to indicate the equivalent of the US concept called "short braking distance".  In the US, where distances between signal masts is less than the prescribed braking distance, "extra" aspects are required to give additional information to the train crew, or, the signal system must implement "doubled" signal indications, such as two or more consecutive masts indicating "Approach" before a mast which indicates "Stop".  JMRI does not have any good mechanisms for implementing "short braking distance" indications.  Some sort of support in JMRI for intelligent "short braking distance" signaling is something I would like to addressed at some time in the future.  Our models tend to compress distances greatly, and thus "short braking distances" between signals tend to be more common than "prescribed" braking distances.

 

Regards,

Bob M.

 

 

 

 

 

 


Bob M.
 

Dave S. wrote "Is there a common set of track circuit codes -or- does each
railroad have their own -or- is it a combination of common and railroad
specific?"

This question deserves my favorite answer: "Yes and no". A buddy of mine
recently explained some details of the workings of "Electricode 4" equipment
operation:

- that the equpiment is capable of transmitting up to 8 (if I recall
correctly!) different code numbers.
- one particular code is generally used for the signal's most-restrictive
aspect, all others may be assigned to suit the installation
- the signal engineer decides which code numbers are used to communicate
which indications.
- the signal engineer decides what the receiver will do with each of the
received indications.
- some code numbers are "less reliable" than others, where reliability
depends on length of track circuit, condition of ballast, electrical
encoding method for the code, and various other concerns.
- those "less reliable" codes tend to have very restricted uses, except
under controlled circumstances.
- where trackage on both sides of a signal use Electricode 4 coding, the
code number assignments used in one direction may be different than the code
number assignments used in another.

So, assuming that I have the details right, the "Electricode 4"
implementation gives two contradicting answers to the above question:
a) Yes, there is a standard set of coding in Electricode - the simple code
numbers are between 1 and 8 (I think), and each code number is encoded
identically on the track signal.
b) No, there is no standard way in which each code is used, with the
possible exception of the "most-restrictive" case.

This does not say that all prototype implementations behave in this way,
simply that "Electricode 4" hardware behaves in this sort of way. But given
the complexities of railroad signaling, I would expect that the majority of
modern coded solutions behave in this way.

Background: Recently, I have been working with a Class 1 railroad Signal
Engineering Manager on a set of signaling projects at a nearby museum. The
railroad in question is a passenger-hauling operation running on US
"standard gauge" track. The railroad's signaling system was installed
initially in the 1990s and has been installed and maintained following
applicable FRA rules.

We were working to revise some crossing protection circuits over this
winter/spring, and had were working on some changes in an instrument case
which included some Electricode 4 hardware. He explained the details of how
the track signal was encoded (of which I have only the vaguest memory), how
the different codes had differing reliablity, etc. All this while actively
making additions and changes to the circuits. As such, my focus was more on
the work than on the learning.

Regards,
Bob M.


Bob Jacobsen
 

A _lot_ of American signaling can be reduced in the way that Balazs, Dick and BobM have discussed.

If we defined JMRI’s (internal, but nothing is ever really internal in model railroading) implementation of signal logic in those terms, it would have some advantages:

i) The size of the coding tables, which are O(N^2) now, where N is the number of aspects, would drop to a part of O(N*n) and O(n*N) tables, where n is the number of codes. For N>>n, this reduces the size of the tables.

ii) Closer to the prototype is often considered a good thing in model railroading.

But there are costs:

iii) Although the size of the tables is reduced, the complexity is not. If both work properly, they contain the same information. The process of down-coding to the n intermediate states seems error prone to me for the average person trying to put together a signal system definition.

Partly, I’m more interested in people being able to create and contribute “good enough for me” signal definitions. Yes, “perfectly prototypical and robust” is better, but if that was the standard for initial creation we wouldn’t have many of them. Having to code via an internal mapping might actually be easier for people with a lot of prototype experience, but that’s not the majority of people who’ve written initial signal definitions.

iv) Not all parts of all signal systems are based on down-codings like this. For example, SP 1930 interlockings are based on full-communication within interlockings: All the aspect relays are available to all the logic. The “Branch” aspects use that. It’s not clear to me from looking at the diagrams that there’s any down-coding there. Perhaps it can be found in the aspect mappings, but that would be a post-hoc step when defining things.

If it’s not always, reliably there, then the code would need to have a way to create the N*N maps anyway. Perhaps the N*n, n*N maps could also exist as an option for suitable implementors/implementations, but maintaining the code for two methodologies also has a cost.


I think the next step is to provide a central place for the aspect mappings of a signal signal system. That was the original request, after all./ Functionally, this is:

1) Have a single file that can contain an <aspectMappings> set.

2) Read that before processing any <appearancetable> files.

3) While processing the <appearancetable>:

3A) Initially, load the <aspectMappings> from the signal file set
3B) Drop any aspects that are not represented by this mast’s appearances
3C) Process the <aspectMappings> in the file, if any, overwriting any that are redefined

There’s a little bit of extra complexity to make sure the file(s) still schema-validate, but I think that’s probably manageable..

Anybody interested in implementing this, perhaps in a different way? If not, I’ll put it on my “maybe summer” list.

Bob