Rodrigo,
Books have been written on this subject, bu let me make a short summary of my personal view:
First of all, IEC 61499 is an extension of IEC 61131, and was created by the same experts that created IEC 61131. The first thing they did was take the IEC 61131 functions block (FB) and add an event input and output to it along with the data inputs and outputs. They also put in place a restriction in that the FB could only manipulate variables associated with that block. And of course you can embed FB's inside other FB's creating composite FB's. In simple terms they created a true object in the IT sense. You call it by setting the input event, passing data through the data inputs, the FB algorithm performs its algorithm on the data and then returns its result by setting the event output and returning the data with the data outputs.
The second really smart thing the inventors of IEC 61499 did was to separate the application model from the system model. In this way I design my application without thinking about the the hardware on which it will run. The system model then takes the application and distributes it to the different hardware resources that I use to actually execute the application. This is called hardware/software decoupling. And its built into the standard.
Event-drive FB's and software/hardware decoupling enable two things:
1/ Really efficient engineering. I basically program my application by assembling a series of hardware-independent composite FB libraries (pre-built, tested and proven-in-use) and then deploying to my hardware architecture which can be centralized, distributed or a hybrid version. Benchmarks against conventional IEC 61131 systems show a gain in engineering of between 3 and 7 times depending on the engineering task.
While this a really important, it's not transformational. Which brings me to the next point.
2/ Portability/Interoperability of FB's. The object-orientation of the FB's combined with the hardware independence allows you to assemble FB's from different programmers that will interoperate in one application, and to run them on any IEC 61499 compliant hardware, ie the software is portable. In addition, IEC 61499 doesn't actually specify the programming language, and so it allows one to embed proprietary IP inside a FB. In essence I have created a world where an EcoSystem can create and sell portable automation apps that can interoperate on multi-vendor platforms.
This is the true transformation that IEC 61499 promises - over time we will move from a world of low-value programming of proprietary systems to a plug-&-produce world where the SI assembles proven-in-use automation apps into one application that I then run on compliant hardware platforms. Only in this way, can we address the complex use cases of Industry 4.0.
For more information on IEC 61499, download the whitepaper "IEC 61499: The Industrial Automation Standard for Portability that Unleashes Industry 4.0".
