An IEC configuration with 70 controllers; challenges, benefits and a discussion on technical decisions

Transcription

1 An IEC configuration with 70 controllers; challenges, benefits and a discussion on technical decisions Julien Chouinard ICS Triplex ISaGRAF Inc Catania Avenue, Suite U Brossard, QC CANADA J4Z 3V6 jchouinard@icstriplex.ca Denis Lavallée 1, Jean-Francois Laliberté 1, Nicolas Landreaud 1, Kleanthis Thramboulidis 2, Philippe Bettez-Poirier 1, Frederic Desy 1, Frederic Darveau 1, Nicolas Gendron 1, Chan-Dara Trang 1 1 ICS Triplex ISaGRAF Inc. 2 University of Patras, Greece. Abstract In order to assess the IEC capabilities and test different types of configurations, the ICS Triplex ISaGRAF team have created a test bench for ISaGRAF s IEC product using 70 cooperating controllers. They are a mix of NetBurner MOD CR (with Motorola ColdFire 5272 microprocessor), and a few PCs. This paper describes the testbed and presents the results of this investigation. 1. Introduction The IEC standard [1] was officially accepted in Around the world, academics and industries have been active in research to invite techniques and design products to leverage the power of IEC based solution while making sure to stay as close as possible to the standard such that solutions coming from various sources could be compatible. Several automation vendors are adopting the new standard and promoting their products by highlighting the IEC capability. Yet, the anticipated benefits of complying with the standard have to be demonstrated. Meeting the initial requirements of Portability, Configurability and Interoperability will greatly depend on the rigor, discipline and willingness of those developing solutions. The ability to encapsulate Intellectual Property (IP) and deploy such IP on various systems is also subject to the adherence to the standard by the community. Beyond these declared benefits, IEC development was also driven by the need to have devices (controllers and intelligent instruments) cooperate and have their distributed intelligence interact rigorously. ISaGRAF [2] is one of the first commercially available tools that support the IEC based development. With more than 500,000 licenses sold, the ISaGRAF is often used in networked configurations with a large number of controllers. It is therefore expected that soon customers will use its IEC capability on a large scale. In applying the concepts of IEC to the most widely used IEC [3] software tool, the ICS Triplex ISaGRAF team had one goal in mind. Take the leadership in the adoption of the IEC standard and pave the way to its acceptance by the various industries. Some fundamental decisions were made by the ICS Triplex ISaGRAF Product Management team in order to meet those goals. The IEC implementation would be a complement to the IEC solution. It would address the needs not covered by IEC and would not be a replacement to IEC Therefore IEC and IEC could coexist in the same system. The State machine used in the ECC would be the IEC SFC language, with a few changes to meet the need of IEC This means that there is no need for automation engineers to learn one more language. The basic logic engine would be cyclic, like the traditional PLC logic implementation, to preserve determinism and stability. This will also entice other automation vendors to adopt the standard within their traditional 1131 architectures. The producer-consumer communication model was adopted since this model can be implemented on any communication stack such as Ethernet IP, DeviceNet, Profibus etc. IEC function blocks would live within a resource, as a POU like any other one in the IEC environment. The IEC function block would be autonomous and only cognizant of the events and data it is consuming and producing. The next step is to determine the scalability and the performance characteristics of the implementation. It is 1

2 also important to consider characteristics such as configurability and maintainability of the new implementation. Since most tests done with IEC are involving 3 to 5 controllers, the purpose of the tests described in this paper is to challenge the IEC implementation in an application involving 70 cooperating controllers. The goal was to evaluate the ease to conceive and create an application, as well as the usability of the IEC basic and composite function blocs. The test would also give an indication of the seamless integration of heterogeneous controllers and finally indicate the level of performance that could be attained with such an implementation. 2. Testbed Equipment In order to perform the test, 70 low cost NetBurner MOD CR (with Motorola ColdFire 5272 microprocessor) were used, assembled in groups of 3. Each microcontroller is equipped with 2 push buttons and 2 toggle switches as inputs and 2 green and 2 red leds connected to their TTL output lines. A picture of such a basic assembly is shown in figure 1. Figure 1. The basic assembly of the demo controller. These controllers have an Ethernet RJ45 connector and run the μc/os operating system. The ISaGRAF firmware was ported to these controllers and all communications are handled over TCP/IP. A total of 24 assemblies were used for the testbed and the communication infrastructure is composed of two DLink 48 port 100Mb Ethernet switches linked by their 1Gb/sec RJ45 uplink. Two DELL Inspiron 6400 laptops running Windows XP pro are also part of the test bench. A picture of the testbed is shown in Figure Test Applications In order to fully demonstrate the efficiency of the IEC standard and the ISaGRAF tool, three applications were developed. All applications are deployed on the same hardware platform that is composed of the 72 controllers described above. These applications are: The signal propagation application: This application is used to measure the event and data propagation in an application. The train simulator application: This application is used to demonstrate the use of basic and composite function blocs to simulate a real world system. The Orchestra application: It demonstrates the power and flexibility of IEC in addressing real time constraints Signal propagation. In the first application, the goal was to initiate a signal from one end of the assembly; the signal would propagate within the first controller and pass onto the next controller, each time turning on the LED of the corresponding controller. Three issues should be observed. 1. The propagation within a controller would be deterministic. 2. The propagation between two controllers would also be deterministic and equal to the one into a controller. 3. The time between each step would be deterministic. The following function blocs were used to perform this test: 3x BottomManagement Basic FB 1x PeriodManagement Basic FB 1x E_Merge Basic FB 69x LedSequencer Basic FB A part of the FB network of this application is presented in figure 3. Figure 2. The ISaGRAF IEC testbed. Figure 3. Part of the FB network of the signal propagation application. 2

3 ButtonManagement FB: This FB is a service interface FB. Depending on the index number, representing the physical input on the board (1=Push button #1; 2=Pushbutton #2; 3=Toggle switch #3 and 4=Toggle switch #4), the FB generates an event on the rising edge or the falling edge at its E01 (falling edge) or E02 (Rising Edge) output depending on the case. PeriodCalc FB: This FB calculates the time period for the led to be ON. The default value is reduced or increased depending on the push button press by the user. After each change, an event is generated to the first LedSequence FB (LedSequenceMain) to propagate the new period value. LedSequence FB: When an event is detected at one of the Dec or Inc Event Input pins, the leds are turn on and off depending on which event strikes first. If the Inc input change, the leds turn on and off in the following sequence: Led4, Led3, Led 2 and finally Led1. The opposite order is realize for the dec event input. In addition, each state change (on/off) of the led is delayed by the period calculated by the PeriodCalc FB. The complete function block diagram for this application is shown in Figure 4. Figure 4. Function block diagram of the signal propagation application. 3.2 Train Simulator. This application intends to demonstrate the ease of configuration of a more complex application. It simulates a train with 23 coaches, each having 3 controllers. A scenario was put in place to set some challenges to the programmers. The objective of the presentation is to simulate the functioning of a train. The train is made with a locomotive and 23 coaches. The following functionality is assumed by the train: Checking the presence of the previous and next coaches. Brakes management Motor management Lighting management Door opening management Miscellaneous functions (ticket inspector s round, electric failure in a coach, ) Equipm ent Locomo tive Coach N 1 Coach N 22 Resources Braking & Checking & Train Motor, Auxiliaries and Miscellaneous # of micro controllers Cycle time 1 40 ms 1 40 ms Braking & Checking 1 15 ms Auxiliaries & Misc ms Braking 1 15 ms Braking & Checking 1 15 ms Auxiliaries & Misc ms Braking 1 15 ms TOTAL 69 The simulation scenario demonstrates the following behaviors 1. Initial step 2. Hitching of the coaches on to the locomotive: 3. Train starting and running 4. Train stopping in the station 5. Emergency stop 6. Ticket inspector s round 7. Electric circuit s failure and maintenance. To develop this application, we used the six composite Function Blocs and eight Basic FB, as listed below. 1x Check_Brake_L Composite FB 1x E_Train Basic FB 1x IO_L Basic FB 1x E_Braking Basic FB 1x E_Checking Basic FB 22x Check_Brake_C Composite FB 1x E_Train Basic FB 1x IO_L Basic FB 1x E_Braking Basic FB 1x E_Checking Basic FB 1x Check_Brake_LC Composite FB 1x E_Train Basic FB 1x IO_L Basic FB 1x E_Braking Basic FB 1x E_Checking Basic FB 1x Misc_Aux_L Composite FB 1x E_Auxiliaries Basic FB 1x E_Motor Basic FB 1x E_Inspector Basic FB 1x E_Technician Basic FB 3

4 22x Misc_Aux_C Composite FB 1x E_Auxiliaries Basic FB 1x E_Motor Basic FB 1x E_Inspector Basic FB 1x E_Technician Basic FB 1x Misc_Aux_LC Composite FB 1x E_Auxiliaries Basic FB 1x E_Motor Basic FB 1x E_Inspector Basic FB 1x E_Technician Basic FB where L is used for Locomotive, and C for Coach. Figure 5 presents the IEC function block diagram of the train simulator application. Figure 5. Train Simulator diagram The Orchestra The third application is used: a) to demonstrate the ability of IEC to be used for synchronizing and coordinating a significant number of controllers and b) to measure the performance of the implementation of such a complex system.. The way to demonstrate this was to design an orchestra application. A conductor sends a tempo event to a set of 5 sub-conductors who read their part of an orchestra partition, and send to the musicians under their control a note and a time to play it. Each musician commands a MIDI player function block the actual info to play in MIDI terms that is wavelength, channel, time, etc. Since all these functions are on different controllers and all signal have to arrive at the same time at the PC that is playing the music, this would show how rigorous is an IEC program implementation. Figure 6 shows a schematic diagram of the concept demonstrated by the Orchestra application. Figure 6. Architecture of the Orchestra application When the user switch Starting playing music the application is activated, and the orchestra is performing. The Conductor of the Music has several Conductor Assistants (Score reader, one for one or several instruments). The sub-conductors have under his order as many players as needed to play his partition. Each player is playing one or several notes (light a led, and send the note to the main PC). One main PC is playing the Music. The challenge here is that we are initiating at a pre-defined tempo an event to indicate which part of the partition to play. The Conductor of the Music sends to the 5 Conductor assistant (score readers) the Rhythm of the partition (event) and the number of the current step in the partition. Three Conductor Assistants are running on the conductor PC and the other two on the second PC. When each conductor assistant receives the Rhythm event, he is looking in his partition which is the note to be played at this step. He then sends to the right player a playing event with the note, the duration of the note to be played as well as the volume. The player is lighting the playing a note led when he is playing. He also sends to the Main PC the note and the velocity during the duration of the note. The following function blocs were used for the development of the Orchestra application: 50x PlayMidi Basic FB 50x E_Musician Composite FB 1x IO_LED Basic FB 1x Musician Basic FB 5x ConductorAssistant Basic FB 1x Conductor Basic FB The complete IEC FB network diagram is shown in Figure 7. 4

5 Figure 8. A snapshot of the ISaGRAF Workbench. 4. Discussion Figure 7. The Orchestra application Function Block diagram All three applications were implemented on the testbed at the same time and some basic logic was done to activate one or the other. The screen shot of the ISaGRAF workbench given in figure 8, shows how it can be viewed from the development environment. This Device View shows a distribution of the FB application across devices. Several fundamental decisions were taken during the development process. IEC is based on the occurrence of events. Some researchers have interpreted the IEC architecture as an event only driven system, and this has led to the need to find ways to predict how events would propagate and how this would behave in real world situations. In reality, the use of events does not mean that the events should be processed at the instant it reaches the controller where a function block is instantiated. The event has to be processed within a time frame consistent with the system capability and with the application timing requirements. In designing industrial control application, mechanical equipment and electronics are always sized to meet the specific requirements. The approach taken here has been to maintain the system under full load. It is understood that event based only systems may have a better response time if 1 event occurs. But for a system where 1000 events would need to be handled at the same time for example, the sequence of execution needs to be determined. And it is assumed that the next occurrence of the same event could not be handled until the 1000 events are treated unless a priority scheme be introduced, which would considerably increase the complexity of the system. By using the scan-based model and implementing the Producer-Consumer model (Figure 9) data and events are produced at each scan. This means that the system is in quasi-full load mode. Under that mode, the overall network traffic is known and the scan execution cycle is fixed resolving any ambiguity as how the system would perform under stress, it is always at maximum capacity. The system is therefore deterministic and very stable. The only difference in performance between the scan-based system and the event-only based system would be the idle time between two scans. 5

6 TCP/IP socket limitations on each controller, Maximum application diagram screen width, Debug communication algorithm to make the Debug mode useable, Programming using IEC methodology instead of standard IEC Test results Figure 9. Producer-Consumer model. If we apply industry standards to maintain CPU usage below 75-80% we can assume that the performance of the two models would be identical under full load. Yet, the scan based model will be totally predictable. The following formulas are used describe the Event x Handling Time. With the Scan based approach Exht = Cd + CTvm With the event based approach Exht = Cd + E1..nCT + ExCT Where Exht = Maximum Event X handling time Cd= Consumer driver processing time CTvm= Virtual Machine computing time. E1..nCT= Event 1 to n computing time ExCT= Event X computing time. While Cd and CTvm are known and pre-defined, guaranteeing a deterministic processing time, the other approach would yield often faster but always unpredictable processing time. 4.1 Challenges in performing the test This project was initiated to demonstrate the performance and viability of large IEC applications. Although the ISaGRAF product has been used worldwide, no test bench of that size were put in place. The decision to use Ethernet with TCP/IP was based on convenience and the fact that Ethernet is becoming the defacto standard in the industry. Part of the challenges were to identify the proper communications parameters to use for a system of that scale since the PCs for example had more than 100 sockets opened at the same time. The technology could be used over any industrial network, but in depth analysis of the default limitations should be made and assessment that the actual final configuration would not exceed the capacity of the selected media is found to be paramount. The following elements had to be adjusted for these applications to be manageable. 1 st Application: Signal propagation The performance and behaviour of this application was very interesting. The signal propagation was performing as expected and the transition between blocs interacting within a single controller and between two function blocs residing on separate controllers was unnoticeable to the human. Descriptions of the various function blocs used are presented in an annex of this document. We can show that the event propagation (LED propagation) follows the model defined by ISaGRAF (scan based, producerconsumer) 2 nd Application: Train Simulator In this case as well, the performance and behaviour of the application was as expected. The signal propagation was in line with the plan and the emergency stop was instantaneous. The time spent on writing the project specification was longer than the time it took to actually write the application. The ability to create composite function blocs and reuse them was a major advantage in reducing the development time. Once the application was defined, the actual programming was straight forward. Subdividing the control elements in basic function blocs and assembling those in composite function blocs enabled us to test the functionality with one coach and then all that was needed was to instantiate these on the other coaches. A complete description of the spec is given in another document. 3 rd Application: Orchestra The results of this test were beyond expectation. The challenges in this application were to write function blocks that could drive the MIDI player of a PC at the same time and to find the proper settings for the memory space, the number of opened sockets and the buffer size adequate to run the application. The most astonishing part of this was that, at once, during one test sequence where we were adjusting the TCP/IP buffer sizes, the whole system started to work perfectly. For use this was the ultimate proof of the long term viability of IEC Integrity of the data trigged by an event was essential in this application. The note, time and volume are needed to be in synchronization to get the proper sound. Any deviation from the predicted timing would be perceptible in the music. In all cases, the difficult par was not the programming of the application or the configuration of the system. Most of the problems were related to the limitations of the 6

7 selected hardware the fine tuning of the operating system on the Netburner microcontrollers. 6. Conclusions In March 2002, the ISaGRAF R&D team initiated an evaluation of the actual potential of IEC Soon it was recognized that this standard might very well be the backbone of the next generations of automation technologies. In January 2003, in isolation, the ISaGRAF R&D team started to implement the required components to meet the IEC standard and had to address each and every challenge posed by this new standard in combining its vast industry experience in designing a leading edge software solution and it s assessment of the essential requirements to meet end user expectations of an industrial grade automation software product. The resulting solution has been released in December 2005 and been improved and used since then in small scale application. The results of the tests described in this document are confirming the long term viability of IEC Automation vendors around the world should immediately act to migrate toward the integration of IEC technology within their product line. Several areas need to be explored; the design of a 70 controller s application was within reach. The next step will be to extend this knowledge to application with more than 1000 devices cooperating. IEC is formally defining the cooperation between devices. Formal testing and simulation methods will be needed to be able validate any application on a large scale. The combination of UML [4][5] and formal testing methodologies are among the areas that will need to be explored to make the large scale use of IEC in industrial application acceptable to the end-users. The new knowledge economy will be characterized by the encapsulation of different types of intellectual property (IP) present in automation into reusable portable software modules (FBs), and by creation of interfaces between various kinds of automation IP [6]. Despite the success of the ISaGRAF IEC implementation, others will need to have equivalent implementations that will meet the spirit of the standard for Compatibility, interoperability and portability. The ISaGRAF implementation is a viable industrial grade solution for control. If used with other technologies such as the agent technology developed by Rockwell Automation for High level, non time critical management, and if made compliant to reconfiguration standards such as FIPA, the way to design complex, agile manufacturing or automations systems will be forever changed. References [1] International Electro-technical Commission, (IEC), International Standard IEC61499, Function Blocks, Part 1 - Part 4, IEC Jan [2] ICS Triplex ISaGRAF, Commercially Available IEC Software, [3] International Electro-technical Commission, (IEC), International Standard IEC [4] K. Thramboulidis, Design Alternatives in the IEC Function Block Model, 11 th IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA 06) Sept 2006, Prague. [5] K. Thramboulidis, IEC in Factory Automation, International Conference on Industrial Electronics, Technology & Automation, (CISSE 05 - IETA), Dec , [6] Valeriy Vyatkin, IEC Function Blocks for Embedded and Distributed Control Systems Design, OOONEIDA - ISA,