Referencing detector logics by component id or index?

[emiltin]

As far as I understand, activating detector logics is done with M0008 by referencing the component id. But when you request the status of detector logics activations with S0021, you get a string with the status for each, referenced by index.

If this is correct, I think it's unfortunate that different ways of referencing is used..

[otterdahl]

It is correct. I think it is better to reference by component-Id (as in M0008), since we need to use component-id anyway for other purposes (e.g.) alarms and there are some inherent problems with simply using a series of ones and zeroes in a string. All detector logics must be placed in sequence and there cannot be any gap in the series.

But the format of S0021 (similar to S0002) is needed for performance. And also, in the real world it is very likely that you'd only like to activate a single detector logic at a time but you'd still like to know the status of all detector logics at the same time. Subscribing to each detector logic individually would cause massive overhead.

[emiltin]

It seems we have two unrelated referencing systems. Regarding overhead, is it the size of the status response you wrory about, or requiring additional messagse?

An ideas is to keep a numbered list of detector logic components, eg:

1: DL_A 2: DL_C 3: DL_F 4: DL_G

And make it possible to subscribe to this list, so you get the updated list when ever a component is added/removed. That way you will be able to tell what compoent-ids the statuses you get back with e.g. S0021 refer to.

[otterdahl]

The overhead I'm worried about is that there would be a need for a separate status response message - one for each component. And there could easily be more than 40 detector logics in many intersections. Updated status of all detector logics is needed, at least upon connection establishment.

If one would like to know the status of 40 detector logics, a status response message like the one below would need to be sent by the TLC 40 times.

{
    "mType":"rSMsg",
    "type":"StatusResponse",
    "mId":"e5688e53-c51e-408a-8075-c3c018a67f56",
    "ntsOId":"KK+AG0503=001DL001",
    "xNId":"",
    "cId":"KK+AG0503=001TC000",
    "sTs":"2019-09-26T13:31:32.114Z",
    "sS":[{
        "sCI":"S0021",
        "n":"detectorlogics",
        "s":"False",
        "q":"recent"
    }]
}

The idea to use a string with ones and zeros may not be perfect, but it was commonly used in TLC's for other purposes since earlier (eg. RS232 terminal interface, which we require all TLC's to have) and at least all manufacturers agreed upon using it.

A numbered list of detector logics as you mention would be a way to solve some of the shortcomings with using a plain string with ones and zeros, but then we need to get the manufacturers involved and convince them to change the format. We need to ask them if they see a problem with the current format and if it is worth the trouble to change it.

[emiltin]

The problem is more on the supervisor side. You need to know what component ids match which indeces., which is more complicated than it needs to be.

The suggestion with subscribing to the index<->component id mapping was to keep the existing format, but just add a way to see how compoent ids map to indeces.

[emiltin]

could perhaps be solved by https://github.com/rsmp-nordic/rsmp_core/issues/13

[emiltin]

Would be good to solve, but perhaps it has complications. Perhaps best solved in RMSP 4.