PLCopen Reusability Level defined

IEC 61131-3 – the Reusability of Software via the PLCopen Reusability Level

Eckehardt Prehn, Member PLCopen PC1.
Product Manager for SIMATIC Engineering-Tools
Siemens AG, Nuremberg, Germany

Eelco van der Wal
Managing Director PLCopen
Gorinchem, the Netherlands

Introduction

The basis for standardization of the programming languages for industrial controllers was started many years ago with the definition of IEC 61131-3. What was not included in this standard was a standardized way of implementation and certification possibilities for the different manufacturers. This was the basis for a group of suppliers of industrial controllers and software environments to create an independent user organization under the name "PLCopen“. One of the goals of this organization, including several committees, is to define certification and accreditation procedures and specifications. The results are well-defined and binding test specifications, with which every supplier can prove the conformity, of their software products to the IEC 61131-3 standard at independent accredited test institutes. The supplier as well as PLCopen publishes the result, a PLCopen certificate of compliance.

PLCopen Conformity Level – Programming in accordance with IEC 61131-3

The experiences gained over the last 2 years showed that PLCopen is a serious name with a good impact on the industrial automation area, and it gains in importance. Increasing costs in the programming and dependencies during integration, installation, test and maintenance, increase the needs for transparent and easy re-usable software. This not only within one system, but also across platforms from different suppliers. This provided the basis for PLCopen to create a new certification level, called Conformity Level, CL, and an exchange format for re-usability, called Reusability Level, RL (see below).The PLCopen Conformity Level will be applicable to all 5 IEC languages in the future. With a certification from the supplier to this level, one shows that the implementation for the certified language is in compliance to the standard. An example of a Structured Text compliant Function Block is shown in figure 1.

((Figure 1 - file "Bild1.bmp" ))

Figure 1: Example of a Structured Text compliant Function Block <

PLCopen Reusability Level, RL – the exchange level for IEC 61131-3 compliant Function Blocks

Over and over again the re-usability of Functions and Function Blocks across platforms is discussed, and these discussions often create more confusion then real answers and solutions. Based on this, PLCopen has decided in their latest meeting to focus more on this theme and to simplify the names for the separate levels. Until now the discussion was focused to X-Reusability and Portability Level, both including compliance and an exchange format. From now on, the themes are Conformity Level, CL, for the compliance statement, and Reusability Level, RL, for the reusability of user derived Function and Function Blocks across certified platforms via exchange.

To realize Reusability Level, certain restrictions apply:

	Both systems, between which the function blocks are exchanged, need to be certified according to "PLCopen Reusability Level", RL;
	The used IEC 61131-3 data types and commands within the Function Block should be supported by both systems.

Which elementary data types are defined in IEC 61131-3 and can be used in the application is shown in table 1 (conform Table 10 of the standard). In addition, table 12 of the standard defines five data type declaration features: direct derivation from elementary data types, enumerated data types, sub range data types, array data types, and structured data types, which can be used also.

No.	Keyword	Data type	No. of bits
1	BOOL	Boolean	1
2	SINT	Short integer	8
3	INT	Integer	16
4	DINT	Double integer	32
5	LINT	Long integer	64
6	USINT	Unsigned short integer	8
7	UINT	Unsigned integer	16
8	UDINT	Unsigned double integer	32
9	ULINT	Unsigned long integer	64
10	REAL	Real numbers	32
11	LREAL	Long reals	64
12	TIME	Duration	-- ⁽¹⁾
13	DATE	Date (only)	-- ⁽¹⁾
14	TIME_OF_DAY or TOD	Time of Day (only)	-- ⁽¹⁾
15	DATE_AND_TIME or DT	Date and time of day	-- ⁽¹⁾
16	STRING	Variable-length single-byte character string	-- ⁽¹⁾
17	BYTE	Bit string of length 8	8
18	WORD	Bit string of length 16	16
19	DWORD	Bit string of length 32	32
20	LWORD	Bit string of length 64	64
21	WSTRING	Variable-length double-byte character string	16

Table 1: The elementary data types as defined in IEC 61131-3 second edition. [Note ⁽¹⁾ Implementation dependent]

Reusability Level, RL in praxis

Let us look to a practical example: on the system of one supplier a Function Block is created in Structured Text, ST, with the goal to reuse this on a later date on a different system from a different supplier. Pre-requisite are that both systems are certified for PLCopen Reusability Level and that the used data types and commands are supported by both systems. Concerning the data types, this means that if one system supports TIME, and the other does not, one cannot reuse this Function Block. Please note that one could never write the Function Block on the system that does not support TIME at all.

Are these requirements fulfilled, than one can exchange this own Function Block between both systems in a simple ASCII format.

Picture 2 shows the principle of the exchange of the function block, where the use of the neutral language Structured Text, ST, is key.

(( Picture 2: file "Bild2neu.ppt"))

Picture 2: PLCopen Reusability Level

With the graphical languages, like FBD, LD and SFC, the exchange of the graphical program is far more difficult, because no standardized export/import format has been defined for these graphical languages. This means that after import there is no guarantee that the same graphical construct will be represented. Although one can exchange the functionality (see below) one loses the additional exact graphical representation. The exact graphical representation is outside of the scope of the current PLCopen activities, but can be supported by suppliers as an option.

To reuse the functionality of a graphical program part, like a user derived function of function block, both systems have to support an intermediate format or language. After import of the functionality the graphical representation in a graphical language is represented as an additional Function of Function Block. With opening of the FB, to read the original program, the intermediate language, or the conversion of it, will be represented.

Of course both compliant systems can use Function Blocks written in ST in their graphical programming tools.

Conclusion

The specification of Reusability Level, RL, is available. At this moment the test routines are developed based on the specification. With the availability of the test software the certification itself can be done. Certified systems can exchange user-derived functions and function blocks based on ST as neutral language.

Several suppliers clearly showed their interest for certification according to PLCopen Reusability Level. Based on this the first certified products are expected in autumn of 2001.