While implementing SAE J3068 LIN communications for electric vehicles and their charging stations, it became clear that the compiler we selected (perhaps like many other compilers) does not support placing the same Signal in more than one Frame, as is suggested by the LIN Definition File (LDF) in J3068 Appendix D.
For background, SAE J3068 sends identical Status Signals in many Frames, often in more than one Frame per schedule. The reasoning behind these redundant Status Signals was that even if one Frame was missed (which we have not yet observed in practice), another Frame would likely get through, carrying the important Status Signals that are required to be confirmed often.
To reconcile this contradiction between what J3068 Appendix D suggests to do, and what our compiler actually supports, our implementation adds suffixes to Status Signal names consisting of the Frame ID number that carries a given Status Signal. See the linked sample LDF (which also contains other clarifications to J3068 edition 1, such as more enumerations).
For example, Frame zero SeVersionList (used in the Version schedule) and Frame 2 SeStatus (used in the Initialization and Operation schedules) both contain the Signal SeStatusOp in the SAE J3068 edition 1 descriptions. Since our compiler ignores the second instance of SeStatusOp in Frame 2 and reports a null for the value of SeStatus:SeStatsOp, we implemented unique Signals SeStatusOp0 in Frame zero and SeStatusOp2 in Frame two.
For more striking examples, note these identical signals:
SeSelectedVersion2, SeSelectedVersion5, SeSelectedVersion6, SeSelectedVersion11
And these identical signals:
EvSelectedVersion3, EvSelectedVersion4, EvSelectedVersion7, EvSelectedVersion8, EvSelectedVersion9, EvSelectedVersion12.
The supporting code merely checks all such Signals for agreement, and then uses that agreed value. The SelectedVersion Signals are static in a connection session (any change initiates a restart), so this is easy. The Status Signals are mostly static, StatusOp changes only when the contactors should open or close.
Perhaps a subsequent edition of J3068 can reduce some of these redundant Signals without risk.
Note that J3068 Appendix D was intended to help implementers get started, and does not impose requirements. So while Appendix D is not optimal for some compilers, Appendix D is not necessarily in error. There are minor errors (or at least lack of clarity) in other parts of J3068, some of which will be clarified in the next post.
