Members Only | Ezine | Links | Legal Notice | Contact us |

NEWS


PLCopen OPC-UA
Client v 1.1
now released


Creating PLCopen
Compliant Libraries
v0.99 RfC




PLCopen
Safe Motion v0.99
Release for Comments

 

 
Extensive report on
PLC market China


PLCopen
presentations
available

 


 

 


 

 




 

 

 

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 -- (1)
13 DATE Date (only) -- (1)
14 TIME_OF_DAY or TOD Time of Day (only) -- (1)
15 DATE_AND_TIME or DT Date and time of day -- (1)
16 STRING Variable-length single-byte character string -- (1)
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 (1) 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.