Standard for contemporary automation

Cur­rent­ly, the indus­try is expe­ri­enc­ing a pro­found change. To remain com­pet­i­tive in the future, more and more com­pa­nies are turn­ing to advanced and IIoT-enabled tech­nolo­gies to increase prof­itabil­i­ty and pro­duc­tiv­i­ty. In par­tic­u­lar, it is impor­tant to unleash the poten­tial of Indus­try 4.0 in terms of greater resilience, flex­i­bil­i­ty and per­for­mance. How­ev­er, the switch to the new solu­tions is often not easy. The rea­son for this is the way indus­tri­al automa­tion sys­tems have been designed up to now.

Although the cur­rent stan­dard has proven to be quite suc­cess­ful in the past, it is reach­ing its lim­its with the require­ments of Indus­try 4.0. As things stand today, users often opt for the end-to-end use of a sin­gle automa­tion device fam­i­ly — with train­ing costs for per­son­nel and spare parts inven­to­ry play­ing a role, for exam­ple. In many cas­es, how­ev­er, these users are forced to accept eco­nom­ic dis­ad­van­tages if, for exam­ple, the desired machine, which fits opti­mal­ly into the pro­duc­tion process, is not equipped with the house and yard tech­nol­o­gy. Indus­try 4.0 there­fore often rep­re­sents a com­pro­mise here. For the def­i­n­i­tion and real­iza­tion of inter­linked sys­tems — regard­less of the sys­tem envi­ron­ment — a high lev­el of think­ing, pro­gram­ming and test­ing is always required. The flex­i­bil­i­ty required for Indus­try 4.0 can only ever be achieved in this way at great expense, espe­cial­ly when the link­ing of the automa­tion and IT worlds — i.e., “OT” and “IT” — comes into play. Either way, the pre­vi­ous stan­dard can no longer keep up with mod­ern demands for flex­i­bil­i­ty, time-to-mar­ket, resilience and agility.

For this rea­son, Norm is a promis­ing stan­dard for the indus­try of the future. Based on this stan­dard, an automa­tion project no longer needs to be con­ceived and designed with sys­tem specifics in mind. Engi­neer­ing takes place quite freely and flex­i­bly on the soft­ware side, and the cen­tral­ly set-up pro­gram struc­tures can be dis­trib­uted to the cor­re­spond­ing con­trollers com­plete­ly inde­pen­dent­ly of the under­ly­ing hard­ware. Even in the case of sub­se­quent retro­fits and con­ver­sions, the mecha­tron­ic com­po­nents can be replaced, removed or added using the plug-and-play prin­ci­ple. This stan­dard thus enables the full poten­tial of Indus­trie 4.0 to be unleashed.

What is IEC 61499?

In a nut­shell, stan­dard IEC 61499 defines a gener­ic mod­el for dis­trib­uted infor­ma­tion and con­trol sys­tems. The fol­low­ing points explain how it can opti­mize the set­up and man­age­ment of mod­ern, event-dri­ven automa­tion sys­tems in the process:

1. hard­ware inde­pen­dence: by tak­ing a hard­ware-inde­pen­dent appli­ca­tion mod­el approach, IEC 61499 enables porta­bil­i­ty of appli­ca­tion code across plat­forms and engi­neer­ing tools from dif­fer­ent ven­dors. Automa­tion appli­ca­tions devel­oped to run on a par­tic­u­lar ven­dor’s sys­tem will also run on anoth­er ven­dor’s sys­tem. Appli­ca­tions can even be freely dis­trib­uted across dif­fer­ent devices, such as con­trollers, intel­li­gent dri­ves, IPC’s, field devices and actuators.

The fun­da­men­tal hard­ware inde­pen­dence sim­pli­fies and short­ens engi­neer­ing con­sid­er­ably and enables the estab­lish­ment of a plug-and-pro­duce prin­ci­ple in automa­tion. The exist­ing pro­gram struc­tures can be eas­i­ly loaded onto new devices and, in the event of con­ver­sion mea­sures, they can be adapt­ed with­out com­pli­ca­tion — a quan­tum leap in terms of flex­i­bil­i­ty and time-to-market.

2. pre­fab­ri­cat­ed func­tion blocks: Func­tion blocks play a cen­tral role in the engi­neer­ing of automa­tion designs in accor­dance with the stan­dard for con­tem­po­rary automa­tion: the user con­nects them graph­i­cal­ly with each oth­er and can also make use of stan­dard­ized man­u­fac­tur­er-inde­pen­dent block libraries so as not to have to rein­vent the wheel again and again. The use of such func­tion blocks sim­pli­fies engi­neer­ing immense­ly, since the inter­faces and thus the method of com­mu­ni­ca­tion between the indi­vid­ual mecha­tron­ic com­po­nents result from the rela­tion­ship of the vir­tu­al­ly mod­eled blocks. If the func­tion blocks are then dis­trib­uted to the var­i­ous tar­get plat­forms, the com­mu­ni­ca­tion between the com­po­nents can be gen­er­at­ed auto­mat­i­cal­ly. Anoth­er advan­tage is that the vir­tu­al func­tion blocks can be safe­ly test­ed and sim­u­lat­ed with­in the soft­ware environment.