Naming and behaviour conventions for FB connections

[Eccles]

What are the rules and conventions in this regard (rules under the standard, that is)? For example, I decided to prefix connections with EI (event input) EO (event output) PI (parameter input, generally "with" EIInit), RO (result output, usually boolean success/failure), DI (data input) and DO (data output). This is analogous to prefixing in languages like C - p for pointer, etc. But someone commented that QI (for one) has a definition under the standard and should just be called QI. However that still leaves a lot more questions than answers: For example, if initialisation fails, should QO be set to false (only) or is it also valid (or even required) to withhold INITO to make sure that the application will not start (this would actually be simpler in most instances, since there is usually an "initialisation chain" leading to application startup). And is INIT reserved for one-time use, or is it ok to re-INIT a function block in order to change a runtime parameter?

[Alois Zoitl]

On Wednesday, April 3, 2013 12:16:52 AM UTC+2, Eccles wrote:

What are the rules and conventions in this regard (rules under the standard, that is)? For example, I decided to prefix connections with EI (event input) EO (event output) PI (parameter input, generally "with" EIInit), RO (result output, usually boolean success/failure), DI (data input) and DO (data output). This is analogous to prefixing in languages like C - p for pointer, etc. But someone commented that QI (for one) has a definition under the standard and should just be called QI. However that still leaves a lot more questions than answers: For example, if initialisation fails, should QO be set to false (only) or is it also valid (or even required) to withhold INITO to make sure that the application will not start (this would actually be simpler in most instances, since there is usually an "initialisation chain" leading to application startup). And is INIT reserved for one-time use, or is it ok to re-INIT a function block in order to change a runtime parameter?

I myself also spent some time thinking on potential prefixing of variables. I didn't come to any conclusion what would be the best. Other options could as well be to start events always with an uppercase letter while variables with lower case.

Regarding the special semantics of certain names: In Clause 6.1 of IEC 61499-1 there is a definition of the meaning and behavior of a certain set of event and data names in the context of service interface FBs. I would refer to this meaning when implementing own SIFBs.

There it is also stated that in case of initialization faults INITO should be sent but QO set to false. If you wire in addition to INIT->INITO also QO -> QI the SIFBs should take care that the initialization chain is handled correctly (INIT with QI false should not perform anything).

IEC 61499 targeted from the beginning reconfigurable adaptive systems. Therefore if you look at Clause 6.1 and the following clauses you will notice that for all the SIFBs a initialization and desalinization is possible. This allows to change and modify configurations during runtime (e.g., activate or deactivate certain application parts in a specific system state).  If you allow to update your configuration with an reinit strongly depends on the service your SIFB is encapsulating. Sometimes an explicit de-INIT INIT cycle may be more appropriate.  However I don't know if this is writen somewhere explicitly. Could be a potential section for the planed reworked IEC 61499-3.

Alois

[James Christensen]

Thanks for the reply, Alois. I was working on something similar
myself. Some additional remarks:
1. Since, in IEC 61499-1:2013, the semantics of INIT/INITO, REQ/CNF,
IND/RSP, PARAMS, STATUS, SD_i and RD_i and their mapping to service
sequences are standardized for SIFBs in 6.1 and for communication
SIFBs in 6.2, it would not be a good idea to use these events and
variables with different semantics in other FB types either.
2. Additional possibilities for handling INITO events:
a) Using QO to enable passing of INITO+ (INITO with QO=1) but not
INITO- (INITO with QO=0) via an E_PERMIT block;
b) Using QO to steer INITO+ to the next block in the normal
initialization chain and INITO- to an error-handling block via an
E_SWITCH.
These hints should definitely go into the next 61499-3!
--
Best regards,
Jim Christensen

[Eccles]

Thanks, guys. I appreciate your insights. Obviously I should invest in a copy of the new version of the Standard. Cheers! Neil