Items for IEC 61131-3, 3rd Ed.

The following items will be included in a maintenance item proposal for preparation of a Third Edition of IEC 61131-3, to be submitted to IEC TC65:

1. Harmonization with IEC 61499, including:
   - Moving some 61131-3 content to informative Annex(es)
   - Adding new content as required
   - Clarifying the definitions of parameters vs. variables.
2. In particular, showing how a programmable controller can be represented as a 61499 device.
3. Including in the Introduction a statement about how IEC 61499 adds value to IEC 61131-3 and vice versa.
4. Considering the items in the formerly proposed Type 2 TR.
5. Consideration of features from the new Edition of IEC 60848 as may be necessary to correct existing problems (if any) in 61131-3.
6. COMPLIANCE CLASSES or PROFILES will not be developed for IEC 61131-3, 3rd Edition; however, a new "cross-reusability" definition will be proposed by the German NC for inclusion.
7. Functions with null values are to be considered. This would require many changes in the Standard with a large "ripple effect", e.g., a new VOID data type; function invocation outside expressions; removal of the requirement for function results to be used in expressions;....
8. Deprecation of features which limit portability and reusability such as the assignment of internal variables to directly represented variables, which is a feature in 61131-3, 2nd Ed. For instance, an ANNEX could be given containing a list of deprecated features.
9. Consider deprecating the PROGRAM type and replacing it with FUNCTION BLOCK types. These constructs are already converging in the proposed 2nd Edition with the exception of the use of directly represented variables (including the AT assignment).
10. Consider the deprecation of features which limit portability and reusability, e.g., use of directly represented variables in function blocks, uncontrolled use of GLOBAL variables, etc.
11. For completeness, the VAR_ACCESS technique given in 61131-3, 2nd Ed. needs a mechanism for the specification by the programmer of the POU type of protection of specified variables from external access.
12. Consider replacing various diverse mechanisms with the VIEW construct according to the following syntax to be included in function block declarations:

    view_declaration ::= 'VIEW' view_name
    view_var_decl {view_var_decl}
    'END_VIEW'

    view_name ::= 'GLOBAL' | 'EXTERNAL' | 'PROG_INIT' | 'PROG_ACCESS' | 'VAR_ACCESS' | 'IO_CONFIG' | app_specific_view_name

    app_specific_view_name ::= identifier

    view_var_decl ::= variable_name privilege ';'

    privilege ::= 'READ_ONLY' | 'READ_WRITE'

    The interpretation of view names would be as follows:

    GLOBAL: capable of being accessed by contained entities.

    EXTERNAL: capable of accessing the variable in a container entity

    PROG_INIT: capable of instance-specific initialization by a containing declaration

    PROG_ACCESS: capable of being accessed by a containing entity at run time

    VAR_ACCESS: capable of being accessed by a generic access path

    IO_CONFIG: capable of being assigned to an explicitly represented location by a containing entity to be accessed by the contained entity. This location would have to be consistent with the variable's type and privilege declarations.

    Application-specific view names might be, e.g., OPERATOR_ACCESS, ENGINEER_ACCESS, PROGRAMMER_ACCESS, etc.

    Visibility of a variable would be restricted to the first level containing entity unless the containing function block instance is propagated outward through the same kind of view.

13. The relationship between 61499-1 and 61131-3 formal syntaxes
14. Replace hardware-dependent language features (direct representation, etc.) with service interface function blocks to provide access to process data.
15. Eliminate VAR_GLOBAL construct or replace with corresponding service interface function blocks to provide access to system-wide global data.
16. Replace VAR_ACCESS construct with service interface function blocks.
17. Replace CONFIGURATION construct with 1499 device/resource model.
18. Introduce 1499 application model, and mapping of sub-parts onto resources.
19. Replace PROGRAM with TASK and FUNCTION BLOCK with TASK constructs with 1499 function block model, using 1499 event blocks to express TASK attributes.
20. Introduce execution control chart programming language elements.
21. Design 1499 function block algorithms using any of the 1131-3 programming languages.
22. Eliminate deficiencies and ambiguities concerning the evaluation order of graphic language elements (e.g. actions, networks, network elements).
23. Means for embedding existing 61131-3 algorithms into 61499 function blocks for distribution.
24. An informative Annex containing guidelines for migration which stress the ability to make a high-level 61131-3 program (FBD) and make it distributable by adding event flow to contol sequentiality and scheduling of execution.
25. Consider improved exception handling beyond EN/ENO.
26. Make truncation rather than error the preferred disposition when an assignment operation tries to assign a new value of current length Lc,new to a string variable with declared maximum length Lmd < Lc,new per NOTE in subclause 3.1.5 of 61131-8, 2nd Ed.
27. Consider deprecating the current Figure 15(b) and replacing it with one which is consistent with Figure 15(a) for the P1 and P0 qualifiers. See NOTE 2 of IEC 61131-8, 2nd Ed., subclause 3.9.2 (Boolean actions).
28. Delete SFC actions from 2nd paragraph of subclause 2.6.4, per NOTE in 61131-8 2nd Ed., subclause 3.9.4.
29. The idea to allow nested comments is useful, but specific constructs to be used should be deferred to 61131-3, 3rd Edition.
30. Allowing variables of class VAR CONSTANT in addition to subranges, signed_integers or enumerated_values as case_list_elements could be useful but is not urgent. It will be considered for 61131-3, 3rd Edition along with possibly bitstring constants as well as a general cleanup of declarations of constants.
31. DAY_OF_WEEK or DOW with associated conversions from DATE_AND_TIME: A good idea for consideration in IEC 61131-3, 3rd Edition.
32. Consider deprecation of subrange data types and variables; this feature is not widely used.

The following items are brainstormed for future consideration (not part of the maintenance proposal): Java, flow chart.