Is there a way to add attributes to InternalElements or should we add a SystemUnitClass for GeneralSignal?

[CocoDico78]

A General Signal is not only an input port and an output port as it is currently modelled by the AML definition (as an InternalLink). A General Signal can have a complex routing which requires exact definition of all stop points. That would be consistent with all other classes having X and Y attribute.

[ipi-equinor]

The commitee understand this issue to be related to classification of signal. Please see Issue #3 as this also cover this subject.

[AlexTxen]

Classification of signals is related to ExternalInterface level (terminals).
Now in AML GeneralSignal is translated to link between 2 terminals. All info about connection is placed on those terminals (like AO/AI, terminal name, etc.) And link itself cannot have attributes (by the AML restrictions). In this Issue it is proposed to create separate object for each link/signal (like we have objects for e.g. FB's), which can have attributes, in order to store graphical coordinates of signal line routing on SCD.

In my opinion, that would differ from how AML is normally used. Introducing new object for signal between terminals will break the link into 3 parts. And instead of normal 12TT1234.AHH -> 12XV1235.LSL connection we could end up with something like 12TT1234.AHH -> SignalObject.In/SignalObject.Out -> 12XV1235.LSL.

But it could be also evaluated, if we can store graphical information about signal line on the terminal level (e.g. include coordinates/graphical routing in output terminal).

[Erik0x42]

For clarification; there appears to be two overlapping definitions (both normative) of the same concept in IEC PAS 63131:2017.
What is defined in section B.4.6 as 'signal line', is defined again in section D.7 as 'general signal'.

This issue #57 appears to raise a question about how we can encode information about the 'signal line'/'general signal' (ref. section B.4.6, figures B.13 and B.14, and section D.7, table D.7, rows 1 and 2), in particular routing (via points with X and Y coordinates).

The question may originally have been asked from a standpoint of seeking to enable loss-less transfer/exchange of SCDs?
As we can see from #56, the committee appear to be aiming for lossy transfers/exchanges (at least via this presently discussed AML data exchange format), requiring only to keep information germane to the logic function.
So it should be clarified if line routing information is deemed of importance, or not.

It is not entirely clear how and where 'normally energized' (or 'normally closed' for inputs) information, which is visualized with a double arrow on the signal line, is encoded into AML in the current version of the library (v0.0.10). We may be able to encode it entirely on one or both endpoints of a 'signal line' connection/InternalLink, with various attributes, but this should be formalized and standardized in writing (in an "AML encoding and decoding rules" document?).

Another interesting point is whether line style (the regular dashed signal line in figure B.13, or the "digital communication link", ie, serial/bus line in figure B.14) is of importance.
Line style should probably be possible to infer from one or both endpoints' configurations/attributes?

[cdenisey]

Discussions have been taken in the workshop held on 21.06.2023, refer to item 7. https://github.com/equinor/iec63131/blob/2c8fa87426e072459c5afc61afd97b1ce53cd28c/MOM%20AML%20Library%200.0.11%20workshop.docx

It has been agreed to open a work group to look at this topic together with the DEXPI initiative.