A Rapid Configurable Embedded Development Framework Kiah Mok Goh, Member IEEE Singapore Institute of Manufacturing Technology Singapore
[email protected]
Benny Tjahjono School of Applied Sciences, Cranfield University, UK
[email protected]
have limited resources. To achieve this, a user friendly components development and holistic modelling environment that allows interconnection of exchangeable software components is required to rapidly develop, embed and configure the solutions. The new International Electrotechnical Commission (IEC) standard IEC 61499 (Lewis, 2001) provides a modelling, designing method that is targeted to manufacturing domain experts. The standard allows encapsulation of control algorithms in easy to understand function blocks. Function blocks can represent execution control based on process state, abstraction of communication/control, event and dataflow using both function block networks and composite function blocks. The research reported in this paper is a collaboration between SIMTech and Cranfield University, which focuses on investigating a rapid configurable framework for distributed manufacturing prognostics using embedded devices. A review of manufacturing prognostics research (Goh et al., 2006) has suggested that there is much interest and potential industrial applications for manufacturing prognostics. It was identified that most previous work has focused on specific solutions for specific domains, mainly using PCbased tools such as Labview and Matlab. Research in holistic approach, common methodology, real-time configuration, prognostics sensor node or network and rapid development environment are the future research agenda set out in this paper. The purpose of this paper is to present a proof of concept of a rapid configurable embedded development environment using IEC 61499 Functional Blocks. Two test cases, which include an XOR Gate for Field Programmable Gate Array (FPGA) and a PID tank level controller for an ARM based Linux embedded system are used in the paper to discuss the potential of the framework. Finally, a research agenda towards a distributed cluster head/sensor nodes distributed prognostics concept is identified. The paper is structured as follows. Section 2 describes in detail the proposed framework for embedded system development. Section 3 presents the IEC Function Block
Abstract Early detection of system failure required continuous monitoring of electro-mechanical system which required embedded prognostics devices. Unfortunately, the current research and industrial solutions do not provide a user friendly and rapidly configurable environment to create ‘adaptive microprocessor size with supercomputer performance’ embedded solution in order to reduce downtime. Developing a solution for various industrial domains can be too time-consuming because the tools and rapid methods for creating embedded reconfigurable solutions are lacking. In this paper, we present a proof of concept of a rapid configurable embedded development environment using IEC 61499 Functional Blocks. Two test cases, which include an XOR Gate for Field Programmable Gate Array (FPGA) and a PID tank level controller for an ARM based Linux embedded system are used in the paper to discuss the potential of the framework. Finally, a research agenda towards a distributed cluster head/sensor nodes distributed prognostics concept is identified. Keywords: IEC 61499, Distributed control systems, Rapid application development, Function Block, FPGA, Embedded System
1.
Anton J.R. Aendenroomer, Member IEEE Singapore Institute of Manufacturing Technology Singapore
[email protected]
Introduction
Early detection of system breakdown commonly necessitates a large number of components to be continuously monitored. In many cases, the system is exemplified by an integrated electro-mechanical system and hence often requires embedded prognostics devices that are small, intelligent and can be rapidly developed and configured by domain experts or system integrators. These devices should, in theory, predict potential failures that may occur in the system. The part in which the intelligence will be needed has to be embedded and configured in ‘real-time’ because these devices tend to
135
and Section 4 explains the modelling environment which leads to Section 5, the source code generation. Sections 6 and 7 describe the development of the proof of concept test cases of an XOR gate and a PID tank level controller. Subsequent sections propose distributed manufacturing prognostics and conclude the paper with suggestions for future research.
2.
2.2. Structuring Stage B: This stage aims to convert the system requirements into various hardware and software components, system level architecture and reusable components structure. Components could be hardware-based, software-based or a combination of both. Each component will have its functions, attributes, interface and control. Components will be the building blocks for the application. The research issues that need to be taken into account are ‘how to decide when the components should be hardware-based, software-based or hybrid’, ‘how to identify the most appropriate structure and architecture’ and ‘how components could be reused and rapidly created’.
The proposed framework
The review and analysis of previous work related to manufacturing prognostic (Goh et al., 2006) has indicated that there are many opportunities for future research in the area of rapid configurable embedded systems. This includes holistic modelling approaches, rapid development methodologies, embedded solutions to process prognostics data at sensor source and realtime reconfigurable and hardware/ software partitioning.
2.3. Templates and Reference Design Stage C: This is a repository of style sheets, software templates, reference design and implementation, either from past implementation or from other sources. Functionality needs to be encapsulated into reusable portable blocks. Style sheets define the style of the target application languages, e.g. C, HTML, C++, or VHDL languages. Style sheets will allow potential code generators to generate the source codes. The templates and reference designs can be reconfigured to new users’ application requirements. This will help in speeding up the development cycle. The research issues at this stage could be ‘how to define the style sheets’, ‘how to make the style sheet interoperable with other open standards such as XML and XSL’, ‘how to decide the most appropriate reference design/templates to use’ and ‘how intelligent self configuration and selection be developed’.
Figure 1. Proposed Rapid Configurable Embedded Development Framework
2.4. Hardware/software Partitioning and Rapid Application Generation Stage D: In this stage, intelligent methods are required to decide which part of the components should be developed using hardware-based, software-based or a hybrid approach. The rapid application generator that generates the codes will be based on the style sheet and requirements specification. One of the research challenges is to provide a real time reconfiguration on resource-constraint embedded systems. Other issues are ‘how to measure rapid development’, ‘how to create a real time partition of application space within the resource-constraint environment’, ‘how to break complex algorithms into parallel algorithms in order to speed up the process and reduce resource requirement’ and ‘how to reconfigure a solution at run-time’.
Figure 1 shows the proposed framework for a rapid configurable embedded solution for manufacturing prognostics. The following sections will describe the component of the framework in detail and the associated issues at each stage. 2.1. Requirements Stage A: This stage captures the technical and application requirements from industrial users. There are many software engineering methodologies and tools available that can be used at this stage. Unified Modelling Language (UML), for instance, is one of the accepted standards for capturing users’ requirements. The research issues to be addressed at this stage could be ‘how to rapidly convert user requirements into application codes’, ‘how to make the methodologies interoperable’ and ‘how to enhance the methodologies to cover both the hardware and software solutions’.
2.5. Reconfigurable Hardware Based Solution Stage E: In this stage, the use of Field Programmable Gate Arrays (FPGA), a chip that has many reconfigurable logic gates, is proposed. The FPGA gates can be configured into various circuits. Some of the circuits can
136
be processed in parallel in order to speed up complex algorithm computation. This solution is more affordable nowadays as the cost of the FPGA chip has dropped significantly over the last few years and it is suitable for computational intensive processing. Some of the research issues to be identified are ‘how a real time reconfiguration can be done on FPGA’, ‘how to make rapid development methodologies for both FPGA and microprocessors-based embedded solutions interoperable’ and ‘how a complex algorithm could rapidly be converted into hardware-based parallel solutions’.
IEC technical committee 65 (TC65) has defined the Function Block standard that is suitable for a manufacturing environment. It is a well defined standard that is simple to understand and can be easily used by both software engineers and manufacturing engineers. IEC 61131-3 (IEC, 1993) focuses on modelling control systems in the Function Block network for centralised programmable and configurable control. It incorporates the concepts of encapsulating functionality of control systems in the manufacturing plant into robust re-usable Functional Blocks that can be easily understood and applied by people who are not software specialists. IEC 61499 (IEC 2000) further enhanced the concepts of Function Block for distributed, programmable, dynamically configurable control. Function Blocks can be easily used for modelling a wide range of manufacturing problems and solutions ranging from small scale logic gates to large scale distributed systems. A Function Block is a ‘functional unit of software application’ that has its own internal data and algorithms. Function Blocks allow functions to run on different resources so that distributed control systems can be constructed. Smaller elementary Function Blocks can be created like software libraries and could be interconnected one another to form a larger Function Blocks for more complex problems. As shown in Figure 2, a Function Block consists of two parts: an algorithm part and an execution control part..
2.6. Microprocessor-Based Solution Stage F: This solution is similar to a PC-based solution embedded in a small device with a smaller microprocessor. It requires an operating system and a software application. The system could also have databases, web servers, or standard software applications such as desktop computers. The only drawback of this solution is that the processing depends on the speed of the microprocessor, which could be much slower than desktop computers. Therefore, the research issues to be resolved are ‘how an operating system could be reconfigured based on user requirements’, ‘how the solution could be reconfigured at run-time without shutting down the entire system’ and ‘how to convert complex algorithms rapidly’.
Event inputs
2.7. Specific Application Stage G: The final application could be, once again, an FPGAbased embedded system, a microprocessor-based embedded system or a combination of both. The system will be small in size and ready to add on to existing machines or equipment. The potential issues in this stage are ‘how to rapidly configure the solutions for different industrial domains’ and ‘how to have self setup and self fixing features if problems occur’.
Instance nam e Event flow
Event flow
Execution Control (hidden) Type name Algorithm s (hidden)
Data flow
Data flow
Internal data (hidden)
2.8. Prognostics Application Stage H: The embedded application could be in the form of a small box, added on to the equipment or it could be standalone or handheld. The embedded solution can have various sensors and intelligent algorithms to process raw data at sensor source. It can also communicate with other systems. The research issues here are ‘how to rapidly convert a standalone application into a distributed embedded application’ and ‘how to synchronise the embedded solution and communicate with other enterprise systems’.
3.
Event outputs
Data inputs
Data outputs
Resource capabilities
Figure 2. IEC 61499 Function Block The top part of the block can be the execution control, which is defined in terms of a state machine. Upon arrival of an event, the state machine will enter into a new state which will activate the algorithms within the block. Algorithms and internal data are hidden within the block which is represented in the lower part of the Function Block. A Function Block can have more than one algorithm sharing the same internal data. The Function Block will be mapped onto the actual resource, process interface and communication for deployments.
IEC 61499 Function block standard
Embedded systems are commonly used in a manufacturing environment. They range from an embedded system on chip, embedded microprocessors, to distributed embedded systems.
137
A Function Block is like an object. It can derive from a basic Function Block type. It can inherit from another Function Block. There are three different types of Function Block: Basic: The Execution Control will use a Execution Control Chart (ECC) that controls the execution of algorithms. Composite/Sub-application: This is a network of basic Function Blocks packaged as a bigger Function Block. Service Interface: This provides an interface between the basic Function Block and external services (e.g. External Communication) that enables deployment in a distributed environment.
4.
checked against the corresponding DTD file to ensure that its structure is valid. An XSL stylesheet consists of a set of rules that determine how specific elements from the XML document should be presented. Each rule has a match criterion that specifies the pattern of elements. Each rule also has an associated transformation that acts on the matching elements. Rules are composed hierarchically because each rule can trigger other rules by using the tag that indicates the hot spots where other rules can be used and become active. The following XSL tags are most frequently used and their meaning is intuitive. is used to select the value of an element from the XML document. is used to specify custom text. and are the if-then-else and switch control structures, while iterates through a collection of XML elements. simply includes the contents of one stylesheet into another. An XSL processor is required to apply an XSL stylesheet to an XML document. The XSL processor reads both the XML document and the XSL stylesheet, and then applies a set of transformation rules from the stylesheet to the XML document in order to produce the desired output.
Modelling environment
The purpose of this paper is to present a proof of concept of a rapid configurable embedded development environment using industrial standards. The methodology followed has the following characteristics: • System-level design/modelling • Rapid application generation/code generation • Utilisation of open standards, open source tools • Exploration of IEC 61499 standard • Encapsulation of functionality into a reusable block The system level modelling employs Unified Modelling Language (UML). UML serves as requirement and system architecture representations. The functional modelling, device and resource management are done using IEC 61499 Function Block diagrams. Function block diagrams could represent each building block. Extended Markup Language (XML) is used for the data representation and intermediate language between different modelling tools. XML is a flexible method of storing different types of information and allows the information to be read and manipulated in different packages. The style sheet is expressed in Extensible Stylesheet Language (XSL). XSL tells how the XML data will be presented in certain language format. For example, XML will define the style of a web-based application by converting the XML data into a HTML file. The project has used XSL to define different language styles so that different source code for various platforms could be generated.
5.
6.
Test case 1: XOR Gate for FPGA
Gate is the fundamental structure of the electronics circuit. The test case is to explore the framework for designing the composite Function Block XOR using basic Function Block AND, NOT and OR. The final source code can be converted into Field Programmable Gate Array (FPGA).
THE CODE GENERATION
An XML document is structured like a tree with nodes that have a name, a text value, named attributes, and child sub-nodes. An XML document can be associated with a Document Type Definition (DTD) document that contains metadata describing the structure of the XML document. The XML document can be
Figure 3. XOR Function Block
138
Figure 3 shows a composite Function Block XOR. The internal of XOR is formed by various basic Function Blocks. In the test case, Function Block Development Kit (FBDK, 2006) is used to capture the design requirement (Stage A of the framework shown in Figure 1) and structuring (Stage B). The detail coding of each Function Block can be hidden from the user. The basic Function Blocks of AND gate, OR gate, NOT gate and composition Function Block XOR gate can be stored in a repository as templates or reference design (Stage C) for future need. FBDK will allow software developers to draw the Function Blocks and embedded detail coding in the Function Block. The system can save the Function Block into XML, Java or HTML format. Software developers can design the corresponding style sheet using XSL or select existing XSL from template or reference design repository (Stage D). A XML-XSL parser is needed to generate the source code by converting the meta-data from XML with the style sheet definition by XSL. In this case we generate the XML to Handel C or System C++ source code (Stage E). Both System C++ and Handel C could convert to FPGA using third parties tools (Stage G).
START: The Function Block is to initialise the CLK and FACE Function Block when operators select WARM START, COLD START or STOP. CLK: This Function Block generates a stream of events at regular intervals. The period between output events is set by the value DT (Delay Time). FACE: This is the User Interface Function Block that display set point (SV), process value (PV) and output (XOUT) bar graph. CTRL: It is a composite Function Block that consists of PRE (pre-condition), ITERM (Integral values), DTERM (Derivative value) and POST (Post condition). CTRL will invoke respective algorithms to carry out PID control and execution. RECORDER: It is the data logger Function Block that displays the trend of historical data. TANK: This Function Block is to simulate the tank. This test case shows a distributed control application using both basic Function Blocks and composite Function Blocks. In this test case, FBDK was used for requirements, design and structuring but a different XML style sheet was created (Stage D) to generate Java code and C code. XML for Java code was used for on screen simulation and C code was used for microprocessor-based embedded system implementation (Stage F). The generated C code was compiled and run in ARM-based Linux or C-based embedded system (Stage G).
7. Test case 2: PID Tank Level Controller PID (Proportional, Integral and Derivative) is one of the fundamental closed loop control algorithms used in process control. PID control uses the error from the current Process Value (PV), the desired process value or Set-point Value (SV), together with the integral and derivative values of the error to calculate a new output value to control the process. In the test case, the tank level controller was modelled using IEC 61499 Function Blocks. The aim was to explore the framework to generate a distributed solution for maintaining the level in a tank. The test case uses both the basic and composite Function Blocks. The system consists of six basic Function Blocks as shown in Figure 4.
8. Discussion and proposed distributed manufacturing prognostics The test cases above have explored the feasibility of the framework using both XOR gate and PID Tank Level Controller. They demonstrated that the framework can be used in both FPGA chip-based embedded system code generation and distributed control system. The generated code can be changed based on the XSL style sheet definition. IEC 61499 does not define the software development tools implementation detail. Current prototype uses existing software tools that are standalone applications and were linked by using XSL and XML (Stage B). The tools are still far away from commercial robustness because they lack flexibility to link with other available tools like XSL-based code generator and ‘drag and drop’ features. The repository structure is also not well defined (Stage C). Nonetheless, throughout the research, the need for automatic conversion, partition and optimisation of generated source code to either a FPGA-based embedded system, microprocessor-based embedded system or hybrid of both (stage D), was identified. Currently most of the conversion, partition and optimisation are done manually by software developers. This research work could potentially move towards real-time adaptive
Figure 4. TANK-Controller Function Blocks
139
partitioning and conversion (Stage G). Real-time adaptive partitioning and conversion will allow multiple algorithms to share a FPGA chip as not all algorithms will be needed in all situations. The required algorithm is loaded onto the FPGA only when required. This method will enable a small FPGA to be used in larger prognostics applications in order to achieve the data filtering at sensor source. In order to reduce manufacturing downtime and equipment failure, the framework need to be applied to manufacturing prognostics applications (Stage H). A potential distributed manufacturing prognostics case study is proposed in Figure 5 as future research.
overhead compared to conventional programming methods. The latter tend to require the users to have a strong computer science background to handle some of the detail memory allocation, cleaning and knowledge of various programming languages for different applications. In the proposed framework, the language is defined by XSL and could change from one language to another without affecting the Function Blocks design. Using code generator can also avoid many programming errors and maintain reusable components in the Function Blocks. This paper has demonstrated the potential application of a rapid configurable embedded development framework with two test cases that generated code for an FPGA-based embedded system and a microprocessorbased embedded system. In this way, an ‘adaptive microprocessor size with supercomputer performance’ solution could be achieved.
Sensor Node Sensor Node 43 42 41 40 39
CLUSTER
38 37
F1 44
0
10
20
30
40
50
Fc
57 3.5
26
42
24 5 73
40
Fi n
22 38
57 2.5
46
20
36 34
References
HEAD
Cluster Head
T1
0
5
0
5
10
15
10
15
5 72
0
5
0
5
Tci n
10
15
10
15
10
15
18
0
5
0
5
Tc
5 15
10
15
10
15
45
FBDK (2006) downloaded from http://www.holobloc.com Goh K.M., Tjahjono B., Baines T., and Subramaniam S. (2006), ‘A Review of Research in Manufacturing Prognostics, 4th International IEEE Conference on Industrial Informatics INDIN’06, to be published in Aug 2006. Lewis R. (2001) ‘Modelling control system using IEC 61499. Apply function blocks to distributed systems’, The institution of electrical engineers, London, United Kingdom. IEC (1993), ‘Programmable Controllers, Part 3: Programming Languages IEC 61131-3’, International Electotechnical Commission, IEC Geneva. IEC (2000), ‘IEC 61499 Industrial-Process Measurement and Control Specification’, IEC Technical Committee TC65/WG6, IEC Draft.
Fin
5 74
44
50
5 72 5 10
43
45 5 70
42
5 05
40 5 68
41 5 00
5 66
Ti n
35
40
Trx
6 34
57 3.5
39 6 32
5 73
50
1 00
150
20 0
2 50
3 00
35 0
40 0
4 50
6 30 57 2.5 6 28 6 26
5 72 0
5
10
15
0
5
Figure 5: Distributed manufacturing prognostics In the proposed distributed manufacturing prognostics architecture, the manufacturing prognostics system has been distributed into cluster heads and sensor nodes. Each of the cluster heads controls multiple sensor nodes. Cluster heads will be able to learn from historical raw sensors data and trend analysis, and set the limit for each sensor node automatically. Sensor nodes will have selfchecking algorithm on the chip so that raw sensor data can be filtered at sensor source. The development framework can be used in this architecture and could apply to various industrial domains. For example, a chemical plant has multiple tanks and mixers, which could benefit from this type of distributed prognostics architecture.
9.
Conclusion
The framework discussed in this paper hides the detail programming from non-programming and therefore is more user-friendly and requires less
140
