IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO.
6, NOVEMBER 2012 1439
Model-Driven Development of Recongurable Protocol Stack for Networked Control Systems Chunjie Zhou, Hui Chen, Naixue Xiong, Member, IEEE, Xiongfeng Huang, and Athanasios V. Vasilakos, Senior Member, IEEE AbstractInnetworkedcontrol systems (NCS), the performance degradation introduced by the heterogeneous and dynamic envi- ronment has intensied the need for recongurable protocol stacks (RPS). In this paper, an IEC61499-based method is proposed for the model-driven development of RPS. The method is enabled by dening a novel RPSfunctionblock(FB), whichunies the commu- nication behavior and interface of nodes in NCS. Beyond existing communication FBs in IEC61499, the parameter reconguration of routing and scheduling table in RPS FB is highlighted as the core of communication layer function to adapt environment and system variations. Furthermore, the method allows for the code reconguration on Java algorithms in RPS FB under different ap- plication requirements. Through porting the Java virtual machine on different platforms, the code reconguration is implemented by reloading the .class le for a specied protocol FB. A case study on the embedded platform, such as DSP/BIOS and ARM/Linux, is conducted to demonstrate the effectiveness and feasibility of the proposed reconguration method for maintaining stable and predictable behavior in NCS. Index TermsIEC61499, model-driven development, net- worked control system (NCS), protocol stack, reconguration. I. INTRODUCTION A NETWORKED control system (NCS) uses a distributed control architecture where sensors, actuators, and con- trollers are interconnected through a real-time network [1]. The communication protocol stack that directly affects the perceived communication quality of service (QoS) plays a critical role in determining the system performance. However, a unied com- munication protocol standard is not available at present for the reasons of commercial benets, history, and multiapplication objects [2]. In addition, the availability of communication re- sources may change unexpectedly [3], due to the variety of Manuscript received April 30, 2011; revised September 16, 2011; accepted February 28, 2012. Date of publication May 1, 2012; date of current version December 17, 2012. This work was supported in part by the National Natural Science Foundation of China under Grant 61074145 and Grant 60674081. This paper was recommended by Associate Editor R. W. Brennan. C. Zhou, H. Chen, and X. Huang are with the Key Laboratory of Min- istry of Education for Image Processing and Intelligent Control, Department of Control Science and Engineering, Huazhong University of Science and Technology, Wuhan 430074, China (e-mail: cjiezhou@mail.hust.edu.cn; hus- thuichen@gmail.com; sxdxhuangxf@163.com). N. Xiong is with the Department of Computer Science, Georgia State Uni- versity, Atlanta, GA 30303 USA (e-mail: nxiong@cs.gsu.edu). A. V. Vasilakos is with the Department of Computer and Telecommunications Engineering, University of Western Macedonia, 50100 Kozani, Greece (e-mail: vasilako@ath.forthnet.gr). Color versions of one or more of the gures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identier 10.1109/TSMCC.2012.2190593 application demands, or the network disturbance. Consequently, the control algorithm in the system will not render the intended results if certain QoS conditions (e.g., time delay) are not ob- served. It is inherently difcult to guarantee punctuality and predictable QoS, because QoS objects of different protocols are hard to be coordinated in a whole when lacking of a unied architecture that species functional and interactions models therein. To cope with this challenge, there has been an increasing emphasis on developing recongurable protocol stacks (RPS) in such a distributed, heterogeneous, and changeable environ- ment [4], [5]. Protocol stack reconguration is the implementa- tion of a software environment that supports exible manage- ment of protocol components. Reconguration behaviors, such as parameter reassignment, service updating, and functionality replacement, will be executed once the environment constraints or system requirements change. Traditionally, most reconguration approaches enumerated all possible strategies that were in general coded of devices, such as the ComScript environment represented by Muhugusa et al. [6] and the feedback control framework by Eracar and Kokar [7]. Current software engineering such as model-driven development can facilitate the development and deployment of complex protocol reconguration process. Motivated by these research works, we proposed architectures for the functionality verication and performance evaluation of RPSfor NCS[8], [9]. The reconguration services for industrial communication stan- dards were discussed, e.g., Fieldbus [10] and Industrial Eth- ernet [11]. However, under the RPS concept, the platform- independent implementation and the compatibility with indus- trial programming language IEC61131-3 is still a challenge. The standard IEC61499 has addressed these issues, which provides seamless interface for IEC61131-3 applications and could be regarded as a model-driven development approach for the rapid deployment of real-time distributed automation systems. The reconguration that is dened by IEC61499 could be automatic without service interruption or with a minimal one [12], [13]. In this paper, we develop a model-driven framework to im- plement a reconguration scheme for protocol stacks of NCS. The standard IEC61499 is used to build FBs representing differ- ent protocol algorithms and interfaces. These protocol FBs are composed to be a unied RPS composite FB, which provides a unied architecture for industrial communication and deals with the heterogeneous and dynamic environment by inherit- ing the advantages of Java and IEC61131-3. Both parameter and code reconguration are enabled with the help of Function Block Development Kit (FBDK), which is the one of famous 1094-6977/$31.00 2012 IEEE 1440 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 Fig. 1. Typical structure of NCS. IEC61499 compliant development environments. On one hand, the routing and the scheduling schemes that are related to the QoS control are highlighted as the core of RPS architecture. In this cross-layer way, the RPS can recongure the parameters of routing and scheduling table at run time to cope with varia- tions from the application, data link, and physical layer. On the other hand, the RPS FB is distributed to different devices with Function Block Runtime (FBRT) environment, which is a jar le providing methods for the running of FBs dened in FBDK. The platform heterogeneous problem has been solved by port- ing of JVM. The code reconguration is enabled by replacing and recompiling the .class le of a certain protocol FB. The remainder of this paper is organized as follows. Section II investigates the background of our work, including charac- teristics of NCS, practices of protocol stack architecture, and reconguration researches in IEC61499. Section III elaborates the framework for the model-driven management of RPS for NCS. In Section IV, a set of FBs and detail data interfaces are devised for the information exchange architecture of protocol stack under the standard of IEC61499. In Section V, a test ap- plication for the proposed RPS FB is built up, and the real-time scheduling and reconguration test are conducted to show how the RPS works and how the real-time performance has been guaranteed. Finally, Section VI gives concluding remarks and future topics. II. RELATED WORK In this section, we discuss the existing subproblems of re- conguration design in terms of communication characteristics over NCS, reconguration methods, and the standard IEC61499 for dynamic recongurations. An NCS is a distributed real-time control system (see Fig. 1). In order to alleviate network loads on one shared medium, the control network that connects eld devices is usually divided into a number of network segments with different application objects. One master node is dened to govern the message scheduling of inner segment and dynamic connections to outer segment, while other slave nodes act as functional nodes of sensor, controller, and actuator which occupy communication resources according to the plan of master node. Due to the network transmission, the performance of the con- trol system is assumed to be affected by QoS parameters such as delays, jitters, packet losses, and link failures [14]. All the real-time data transmissions meet the delay bound is the most important performance indicator for NCS. In order to assure good performance, the time delay from sensor to controller, or controller to actuator, should be controlled in a certain range by communication protocols. If the controller does not receive any response before the deadline, the control performance would be degraded [15]. More specically, the time delay is composed of four parts: the sending, waiting, receiving, and transmission de- lays. The sending and receiving time delays are divinable when the computation capability and the standard of message handling process are determined on a specic platform. Comparatively, the waiting and transmission time delays are undeterministic, which depend on the communication environment (e.g., trafc load, bandwidth, and transmission paths) and the way to share communication resources. All these time issues are highly in- uenced by the software architecture design of communication protocol stack. In order to realize the RPS supporting many different kinds of critical real-time applications and network protocols in NCS, the following two fundamental problems have to be studied. The rst consideration is to characterize and model the system structure, trafc classication, and timing constraints. Accord- ing to the survey of industrial real-time communication [10], [11], it is possible to model general functionalities (or work- ing mode) in an additional module to accommodate different protocol standards. These general modules are formed together as the backbone of protocol stack, and they would perform a new function that adapts to variegations in requirements when being recognized. Motivated by these, we attempt to provide a unied framework for the support of reconguration manage- ment to accommodate heterogeneous protocol standards and different application objects. Considering the real-time issue, the scheduling scheme that manages the message sending inter- vals on the communication channel has a close relation to the waiting time delay [16], and the routing scheme that governs the transmission paths and network topology determine the trans- mission time delay [17]. Thus, these two QoS related schemes should be highlighted as the core of protocol stack. The second problem is the question of how to design a data interface with real-time features and to provide a real-time in- tertask communication channel that concurrently carries inter- reconguration jobs between protocol modules. An explicit specication is needed for the real-time processing both inside and outside protocol stack at the level of data frame structure among software modules. In the communication community, the heterogeneous standards and the changeable environment have both intensied the protocol stack to be capable of the reconguration ability. Researchers in networking community had begun to pay more efforts on the design of RPS since the 1990s [6]. The work of Muhugusa et al. [6] presented a hierar- chical framework to construct adaptive protocol stacks by the replacement of an entire protocol stack with a new one. Eracar and Kokar [7] implemented the recongurable software archi- tecture that can adapt to changes in software requirements. The ZHOU et al.: MODEL-DRIVEN DEVELOPMENT OF RECONFIGURABLE PROTOCOL STACK 1441 architecture implemented as separated microprotocol modules was given in the work of Denazis et al. [18] and Bridges et al. [19], which supported a framework to construct congurable protocol services. However, these frameworks lack a direct in- terface for the industrial application standard IEC 61131-3. The International Electrotechnical Commission (IEC) has ad- dressed the reconguration issue by the standard IEC61499, which is compliant with IEC 61131-3 applications and a model- driven development approach for the rapid deployment of real- time distributed automation systems [20], [21]. The most im- portant concepts of IEC61499 are an eventdriven execution model, a management interface capable of basic reconguration support, and the application centered engineering methodology [22]. Various researchers developed reconguration methodolo- gies for the industrial communication based on IEC61499: The research project TORERO [23] focused on plug-and-play and self-(re)conguration of eld devices in a so-called total life- cycle approach that utilized IEC61499 to model control logic, but still the system had to be stopped for deployment of code to the devices. Rooker et al. [24] discussed the dynamic recong- uration management method zero downtime reconguration for downtimeless system evolution of control applications on basis of the standard IEC61499. Brennan et al. [25] exploited multiagent techniques to allow the system to recongure au- tomatically in response to change. In general, these analyses are based on specic logic formalizations and applied in the reconguration of system components, but not for the protocol reconguration that affected the networking performance of a distributed system. Considering real-time communication links between devices, Weehuizen and Zoitl [26] showed a framework for the imple- mentation using EtherNet/IP as the communication medium. In [27], the authors proposed a scheduling attempt supporting real-time constrained execution within an IEC 64199 device. Froschauer et al. [28] cover the modeling frameworks for the diverse communication links with different protocols and QoS constraints and used the architecture analysis and design lan- guage (AADL) to extend the IEC61499 modeling ability on the QoS denition and validation. In [29], the authors applied the integration of the AADL Software model and the FDCML Hardware model to reduce the engineering time by an automatic conguration of the communication networks. Similar to these works, we use a pure IEC61499 framework to give a genetic RPS FB for distributed automation systems. The RPS framework is focused on providing the real-time communication services with the routing and scheduling algorithm inside protocol algorithm, rather than the executions between FBs. Based on the RPS framework, parameter reconguration and code reconguration are supported by the IEC61499 environment, such as FBDK. The tool FBDK can supports the whole reconguration life cycle [30]. It is capable of dening FB types, and designing FB diagrams, resources, and devices, as well as provides a Java interface that lets the engineer to visually test his dia- grams. Similarly, the project FBRT and Archimedes System Platform [31] also made big efforts on the issue of generation of executable code from FB design specications. However, it is important to note that the RPS framework is not limited to any IEC61499 development tools. Our reconguration idea of proto- col stack is shown by explicating a set of IEC61499 components and interfaces to accommodate different protocol standards, rather than relying on a xed repository of predened protocol congurations. III. RECONFIGURATION MANAGEMENT OF RECONFIGURABLE PROTOCOL STACK FUNCTION BLOCK RPS requires software architectures that are exible and can support tools and algorithms from a variety of sources and do- mains. The management is the key to implement the RPS. It allows applications to dynamically adjust the parameters cong- uration of each layer or mix and match protocol FBs according to control requirements and network availability. This section introduces a model-driven framework realizing the recongura- tion management process of the code and model space on basis of the information exchange architecture of RPS. A. Management Structure A management structure is devised to control the recongu- ration procedures of protocol stack that reacts to changes in the network and user environment. Fig. 2 outlines the recongura- tion management framework that serves as a general workow to deal with the interaction between individuals and coordina- tion with environment during the reconguration process. The framework manages the parameter reconguration and code reconguration with processes of model description, code vali- dation, performance evaluation, and algorithm optimization. 1) Model Description: Beneting from the IEC61499, all structural, functional, and data aspects of the protocol stack could be added to composite IEC61499 FBs. The IEC61499 is taken as the basis of our model-driven devel- opment technique that keeps track of data ows, identies the type of changes, evaluates the reconguration result, and generates a new stack code accordingly. 2) Code Validation: With the help of JAVA, our proposed framework for the implementation of RPS could detect the functional inconsistency or errors with controller de- mands. Once the validation passed, the new protocol FB could be porting to different environment. 3) Performance Evaluation: The given protocol stack FBs would be deployed in a specied system scenario. Given the set of architecture and environment blocks dened for the system, the execution of protocol stack is inuenced by the aspects of computation ability, resource availability, and transmission time delay. Then, evaluation results, e.g., delay constraint, network utilization, and efciency, are compared. 4) Algorithm Optimization: In the case of communication performance not satisfying with the control requirements, the parameter conguration inside the protocol FB would be rst acted on the changes in routing and scheduling table to adapt the environments variations. Otherwise, if the system or environment changes severely, e.g., new ap- plications or new hardware platform is required, the code reconguration is performed as the procedure of algorithm 1442 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 Fig. 2. IEC61499-based reconguration management framework. optimization by fetching a new protocol le (dened as the .class le) from the block library to replace the old one and enhance the related protocol functionality. The new protocol les are packeted and physically transported over network. In this manner, the core reconguration mechanisms, routing and scheduling procedure, are fun- damentally changed to provide a more intelligent rule to deal with the new task sets or link conditions. For exam- ple, the rate monotonic (RM) algorithm would be good at the low network load, but with the increasing work- load, the early deadline rst (EDF) algorithm could be seemed as an option of optimized scheduling algorithms. Moreover, master/slave polling is required in some strictly conditions to guarantee a deterministic delay. Besides, this IEC61499 compliant framework should maintain the con- struction consistency among the (new) performance model and the system conguration. B. Architecture of the Protocol Stack The layered protocol stack usually consists of ve layers: physical, data link, network, transport, and application layer (APP) with reference to the open systems interconnection model. Motivated by the existing layering architectures [10], [11], protocol functionality and layer compositions are recon- structed to better sever the reconguration viewpoint, which consists of the communication link layer (CLL), the network transmission layer (NTL), and the APP. This new architecture emphasizes on utilizing cross-layer information to constrain the working of recongurable routing and scheduling scheme. The architecture for internal information exchange inside the pro- tocol stack is shown in Fig. 3; especially, the interfaces (e.g., system model, node model, protocol data unit analyzer, and net- work status) for the external exchange are located in the protocol layers. The characteristics of RPS could be described fromthree aspects: working mode, routing, and scheduling. 1) Reconguration of Working Mode: Commonly opera- tion mode and fault mode are the two basic working modes of media access control (MAC), except for the conguration mode. The mode switching is controlled by the node self- status and neighbor status. The former is the running condi- tion (e.g., remaining energy, available free space) of the hard- ware and software itself, and the latter is the sensing result of neighbor nodes (normal or abnormal). Once an error hap- pens, it will be recorded in the sending or receiving vector of MAC controller and issues an interrupt signal from the MAC controller to the CPU. After that, protocol data unit ana- lyzer checks the fault type and starts the Interrupt Manager to switch the working mode of MAC controller from the normal ZHOU et al.: MODEL-DRIVEN DEVELOPMENT OF RECONFIGURABLE PROTOCOL STACK 1443 Fig. 3. Architecture of RPS. operation to the fault mode. The reconguration of working mode is to guarantee that the fault node does not interfere with the working of others until it become normal again. The IEC61499 framework implements a set of hardware drivers or operating systemapplication programinterfaces (OS APIs) call- ing methods for this working mode reconguration in CLL. 2) Reconguration of Routing Table: The topology structure in the open-network control systems is always heterogeneous and changeable. When new devices or tasks are added to the system or someone is out of work, the topology of the NCS would be changed; then, the routing tables distributed in the master nodes are required to be recongured to update network- ing paths for such a new data transmission requirement. Other- wise, the QoS value (e.g., the transmission delay) may increase or decrease unpredictably and leads to performance decreas- ing. The routing reconguration of NCS is a very complicated combinatorial optimization problem, which can be similar to the NP-complete problem, such as bottleneck traveling sales- man problem. Thus, some intelligent algorithms are required to improve the searching ability for the complex solution space. In the previous work [17], an improved mechanism based on genetic algorithm was designed to nd the minimum time-delay path for the routing table reconguration. 3) Reconguration of Scheduling Table: The problem of network scheduling in NCS is to assign a transmission table (in master nodes) for each message (issued by the nonperiodic and periodic tasks in slave nodes) on the shared communica- tion media according to the scheduling algorithms (a set of time and event triggered rules that determine the order in which messages are transmitted). Based on the QoS, the parameters of scheduling algorithms, such as bandwidths for the periodic tasks and the nonperiodic tasks, the polled sequence of slave nodes, and the length of a time slice, will be recongured accordingly to renew the transmission table (i.e., scheduling table). In the IEC61499 modeling framework, the scheduling procedure is dened as a protocol algorithm in the NTL, which calculates a new scheduling sequence (stored in a table) for the remote operations between the master and slave devices. The algorithm is imitated by the task information of system and triggered by the QoS_Change event and the scheduling table will be updated at run time for controlling the QoS at a required level. IV. IMPLEMENTATION OF THE RECONFIGURABLE PROTOCOL STACK WITH IEC61499 In this section, we show the details of protocol state ma- chines (i.e., event control charts) and data interfaces for the internal information architecture according to the model-driven development standard IEC61499. The major advantage of the 1444 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 Fig. 4. Composite FB of RPS. IEC61499 architecture is that it addresses the higher level aspects of communication, cooperation, and decision making among nodes of NCS. Details on how the IEC61499 supports reconguration management and distributed communication are fully discussed in [21], and [25][29]. Here, we focus on ex- tending subscribe/publish service (i.e., user datagram protocol (UDP) socket) with a reconguration support for communica- tion activities among control applications. This enhanced com- munication service block is an integrated resource model that consists of three basic blocks for the layer specications of RPS. A. Modeling the Recongurable Protocol Stack The model for the architecture of RPS is depicted in Fig. 4, which is mapping fromthe interface and workowof Fig. 3. The model is considered as a composite FB that provides three kinds of protocol services: sending, receiving, and reconguration. Before the running of RPS FB, the initialization of input (INTI) and initialization of output (INTO) events are used to initialize the node platform resources (e.g., CPU, primary and secondary storage, and various I/O peripherals), and the sys- tem information (e.g., network scale, message path, packet size, real-time type, and demanding QoS value). The sending service is accessed by the user program that could be any type of re- mote control applications, which is controlled by the event ow Send_REQ FromAPP_REQ NTL_REQ, and generat- ing the data owUser_Task APP_data NTL_Packet. On the side of receiving service, another FB execution ow starting from the CLL layer is required. The transmission control algo- rithms in NTL are triggered by the complement conrmation of frame receiving (Net_CNF). Then, the user program begins to receive the data once receiving the request event (APP_REQ), which represents that the process for decoding and queuing NTL_Packet has been done. The complement of receiving ser- vice is denoted by the event APP_CNF. The parameter reconguration service that is dened in the routing and scheduling algorithm in NTL is triggered by moni- toring the QoS information (QoS_Change) that contained in the receiving CLL frame. The request event for NTL_Packet rerout- ing (ReRoute_REQ) is triggered in the case that the end-to-end delay violates deadline due to the performance degradation of one of the router devices in the original path. The request event for the rescheduling of APP message (ReSch_REQ) is trig- gered on the situation that the workload on sharing resources is increased suddenly with a slave nodes added in. The new node will lead to CLL frames appearing on a new port. In this RPS FB, all the protocol algorithms are implemented in the JAVA language and apply the Java Native Interface (JNI) method. The JNI can interact with other programs written in other languages such as C, C++, and assembly in .class les for the fullling of these RSP services [32]. The APP block is the interface between the protocol stack and users to collect the node information and interpret the User_Task. It provides high reliable data services for the ap- plications on the user layer. The interface User_Task is respon- sible for input of task queues with periodic and nonperiodic. The change of system structure or task requirements would transfer through the data channels of Node_Info TaskTable and Sys_Info TopoStructure, which reinitialize the congura- tion of platform resources that are required by the scheduling and routing algorithm of NTL. The NTL block is mainly composed of three parts: the data channel, the scheduling scheme, and the routing scheme. The scheduling scheme is to assign a time table determining the sending intervals for each transmission entity, both nonperi- odic and periodic tasks. The scheduling table is constructed as a specic string format, which is broadcast to the subscribed devices to control the trafc between the APP and NTL. The routing scheme can provide the QoS-guaranteed end-to-end data link service for the scheduling scheme. It determines the next hop address in the NTL_Packet forwarding with the assump- tion that transmission delays are all bounded into a certain range. The CLL mainly represents the functionalities of physical layer and the data link layer. In common, they are integrated in a special-purpose chip. Thus, the CLL is the emphasis of hard- ware reconguration that is concerning the appropriate param- eter conguration on the hardware chip. The port QoS_Change is to report the peer-to-peer link status. ZHOU et al.: MODEL-DRIVEN DEVELOPMENT OF RECONFIGURABLE PROTOCOL STACK 1445 Fig. 5. FB of APP. (a) Interface. (b) ECC. B. Protocol Stack Components The RPS FB is to provide the communication service for the remote tasks, and the APP layer block is the interface for the user FBs. Then, the application data are then coded into the payload of routing protocols and the trafc ow is controlled by the scheduling scheme. The scheduling process is relied on the reconguration of NTL. In other words, the recongura- tion of NTL is processing the algorithms of topology control, scheduling, and routing. The CLL is concerning the appropriate parameter conguration on the working mode of the hardware chip. 1) Application layer: The APP is to represent information of node and system, message coding and decoding for a specic task, and the queue management of User_Tasks. As depicted in Fig. 5, the initial state of START is to indicate that the protocol stack is ready for providing communication service. The other states in the execution control chart (ECC) can be described as follows. a) INIT: It is the initialization state to prepare the information of TaskTable and topology structure for reconguration activities. b) Q_Operation &TaskClasscation: They are the states that represent the queuing of nonperiodic and periodic tasks. In order to avoid the task stack overow, both sending and receiving queues are needed to represent the processing capability of RPS FB. The algorithm Q_Operation con- tains the PUSH, POP, and Resort operations for the queue manage. After the state of TaskClassication, the peri- odic and nonperiodic tasks PUSH operation is distinct, i.e., the former is performed according to time trigger table (the rescheduling result) and the latter is inserted in queue with high priority received during a nonperiodic task declaration. On the message-receiving side, the algorithm DCodeUserTask abstracts the user data from the NTL and analyzes the network status report that is contained in this NTL_message to decide whether to accept the receiving user data and PUSH it into the queue of NTL_message. This process is often implemented to guarantee the cor- rectness and credibility of user data. c) SendToNTL & SendToUser: They are the states that rep- resent the process of coding and decoding the User_Tasks and NTL_Packet. The state SendToNTL is the lling of user data into an NTL_Packet, while the SendToUser is to analyze the NTL report to deliver required data to the corresponding User_Tasks. 2) Network Transmission Layer: NTL is to provide a QoS guaranteed scheme for the stabilization of environments varia- tion and optimization of control performance (see Fig. 6). The states that are dened in ECC could be classied into three cat- egories: the message channel, the rerouting mechanism, and the rescheduling mechanism. a) SEND & RECEIVE: One important function of these two states is the coding/decoding of data frame with differ- ent transmission protocols. On receiving the request event FromAPP_REQ, the Packet head is written before the string of APP_Data to form a specied network packet for network transmission, for example, the packet head could be IP head here. On the other hand, each frame receiving from the CLL is decoded in the algorithm DCodeCLL_Frame to identify which channel it belongs to. b) TransControl: It is the state that is under the control of scheduling signals. It comprises two processes: one is for 1446 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 Fig. 6. FB of NTL. (a) Interface. (b) ECC. real-time trafcreal-time (RT) channel, the other is for nonreal- time trafcnonreal-time (NRT) channel. The RT channel only implements the necessary functionality of packet assembling or disassembling. The NRT channel includes standard proto- col TCP/UDP. It provides a seamless integration to the com- mercial protocols, like HTTP, FTP, etc. A timer in the both algorithms of RT_Channel and NRT_Channel is used to decide the event FromCLL_CNF that informs the APP block that a new NTL_message is ready. The outdated message would be discarded. c) ReRouting: This state is the kernel of routing recon- guration, which is followed by the missing or failure result in the state PathQuery and determines the next hop address for the state forwarding. The received message will be forwarded to the CLL directly by the algorithm UniCast on the case that the des- tination is in the same network segment; otherwise, it will nd the next hop address in the neighbored segments. Fig. 7 shows the workow of algorithm SPF (Shortest Path First) for the state ReRouting. SPF is responsible for updating the next hop address information in the routing table when the cost of old routing path is out of the delay bounds. The SPF is a graph search algorithm that solves the single-source shortest path problem for a graph with nonnegative edge path costs, producing a shortest path tree, and the tree is distributed into the next hop information for the packet forwarding. The tree of forming SPF is based on the service of topology control. The changing of topology graph will affect the vector to perform the SPF algorithm. Thus, the parameter of SPF could be changed in QoS or system informa- tion, and, nally, the SPF can calculate a new address parameter for the routing table. Moreover, for our IEC61499-based RPS framework, the SPFalgorithmwould be easily updated by others when the problem is more complex and the searching efciency does not fulll the real-time requirement. Once a transmission request appears on the NTL, the routing frame is formed with a general data structure as Preamble | SFD | Destination Address | Source Address | Protocol Type | Data | Padding | FCS. All the referring segments should follow a certain communication standard, for instance, the IEEE 802.3 for Ethernet. In addition, depended on different QoS levels, the Data eld could be varied from different routing service. d) ReScheduling: This state activates QoS_changes in CLL that trigger the event ReSch_REQ. Then, the state ReScheduling will recalculate the scheduling table with an algo- rithm for the arrangement of sending intervals of messages. The scheduling message (SchMSG) is generated in the state of syn- chronous transmission (SynTransmission) and asynchronous polling (AsynPolling). The data structure for TaskTable and scheduling table (i.e., SchMSG frame) is shown in Fig. 8. First, the transmission sequence of message task is determined by an algorithm like EDF. Specically, such a exible data struc- ture is derived from the work of Pedreiras and Almeida [33], which efciently supports hard-real-time operation in a exible way, seamlessly over shared or switched Ethernet. Similar to the ReRouting state, the algorithm in the state ReScheduling ZHOU et al.: MODEL-DRIVEN DEVELOPMENT OF RECONFIGURABLE PROTOCOL STACK 1447 Fig. 7. Data interface for the routing reconguration. Fig. 8. Data interface for the scheduling reconguration. could be recongured with the component of weight fair queu- ing (WFQ) and RM, under conditions that the EDF cannot gen- erate a schedulable sequence for the increasing workload. We considered the reconguration of algorithm replacement on the assumption that the required resources do not exceed the the- oretical maximum workload on a sharing media. Second, the scheduling table is formed as a set of element cycles (EC) that represent the trafc within a certain period. The size of each scheduling table should be equal to a macro cycle, which com- prises enough ECs for polling all the tasks of slaves once an algorithm Assemble_Sch_Frame uses the task sequence of each EC line to assemble SchMSG, which is broadcasted from the master node and allocates a time slice for the task in each slave. The parameter reconguration of scheduling table is in a style of plan to plan, i.e., replaces the old SchMSG with a new table in data led to cope with possible changes in the task set and the variation of QoS. 3) Communication Link Layer: CLL is to provide a reliable peer-to-peer link (see Fig. 9). The ECC that is depicted in Fig. 9 shows the switching between the mode of normal operation and fault processing for hardware conguration. a) SEND & RECEIVE: They are the general states of send- ing and receiving, which represent functionalities of mes- sage assembling and disassembling procedure. The algo- rithms of NetComm_Write and NetCom_Read are imple- mented by the JNI method to read and write the data into communication controller (a hardware device). The pro- cess of CheckLinkStatus can issue an event QoS_Change to announce for the scheduling reconguration in NTL. 1448 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 Fig. 9. FB of CLL. (a) Interface. (b) ECC. b) Fault: It is the state for the fault processing that could be activated by the conrmation of routing reconguration. The fault may be of two types: one is caused by the conict and the other is referred to the link error. For the former, the algorithm BackoffAndRetry will start a random delay timer for the resending of blocked frames. Meanwhile, the algorithm CheckLinkStatus is used to match the error code provided by hardware APIs. Once the link error is identied, correcting operations will take a while before switching back to the idle state and may issue the event QoS_Change to inform the NTL the loss of neighbor node when the error counter exceeds a certain default value. c) TimeSynchronous: The algorithm TimeSynCal for this state is used to maintain a global clock for all master and slave nodes in one network segment. Based on the global clock, the TimeSynCal implements the precise calculation of QoS value (time delay) for the ReRouting process in NTL. V. CASE STUDY This section focuses on the reconguration process in more details. In the shop oor of NCS, various real-time mechatronic systems exist in the form of embedded controllers, industrial PCs, and programmable controllers [34]. Under this concept, we used the model-driven development environment FBDK to prototype our RPS FB on different embedded platforms (e.g., DSP and ARM) to support future applications on PLC or in- dustrial PC. Experimental results can help us to get better ideas on the implementation of RPS and evaluate the cost of code reconguration. A. Test System Conguration A test application for the RPS FB is given in Fig. 10, which is a bus communication system containing two device types: the master manager and the slave device. It is typical network architecture for NCS, for example, the DeviceNet dened by the ROCKWELL Crop. In this architecture, the application method of RPS FB is similar to the mechanism of Publish/Subscribe model in the library of FBDK, not only providing a UDP con- nection service, but also encapsulating the algorithm for the guarantee of real-time performance through parameter recong- uration. Of course, the code level reconguration is supported, i.e., RPS FB can adapt its communication service for different bus protocol applications by reloading a .class le for the Java native implementation. In detail, the master manager is responsible for schedul- ing message transmissions in the segment, collecting the data from slave devices using the Ethernet frame and capturing the QoS_Change events to perform the reconguration service on the routing and scheduling table. In this case, each slave device periodically generates data to the master, and the master displays the receiving results. Within the master, UserCTL is the control panel to display the slave data, and in the display, a special FB to access the .txt le is developed to record packet and interface with a third part data analysis tool. The scheduling algorithm in RPS can coordinate different periodic tasks in a nonconict way to avoid the delay variations. The routing algorithm just ZHOU et al.: MODEL-DRIVEN DEVELOPMENT OF RECONFIGURABLE PROTOCOL STACK 1449 Fig. 10. Test application for the RPS FB. performed the role of discovering a new device added in and assigning its IP address in the table of master device, since the router device is not used in this case study. As for the slave devices, the basic RMT_DEV is introduced with the RPS FB to improve UDP services. The hardware platform for running the test application is given in Fig. 11. The application conguration le and the mas- ter manager are running on a PC (with CPU of Intel Core- 2 2.6GHz). The slave is implemented as an RMT_DEV and running on different embedded platforms, such as ARM/Linux (S3C2440) and DSP/BIOS (TMS320C55xx). The JVM version for running the FBRT is JamVM with the GNU ClassPath. In our test, a compact set of ClassPath-0.92 (containing the packages namely java.lang, java.io, java.util, and java.net) is used, and a method isEmpty() is demanded in the String.java before compiling this compact set. Thus, space requirements for the remote execution of FB are: 1) Jam VM 1.4.3: 556 K; 2) ClassPath-0.92: 2.63 M; 3) FBRT: 432 K; 4) RMT_DEV with RPS FB: 1 M. For example, the procedure for remote starting of RMT_DEV on an ARM/Linux platform is as follows: #export LD_LIBRARY_PATH = /home/classpath/lib/ classpath #export BOOTCLASSPATH = /home/jamvm/share/jamvm/ 1450 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 Fig. 11. Hardware platform of the test system. classes.zip:/home/classpath/share/classpath/glib j.zip #./../jamvm/bin/jamvm -classpath lib:fbrt.jar fb.rt.RMT_DEV -p events:ita:mach:net -s 1234 B. Experiment Results Under experimental system setting, the performance on pa- rameter reconguration and code reconguration could be eval- uated. First, for the parameter reconguration test, we initialized the system information that only contains the tasks in SlaveDe- vice1 and SlaveDevice2, and then, increased system tasks by starting the other slaves during runtime. This way, we could nd the reconguration result of scheduling table, i.e., the in- sertion of new tasks into the original task sequence. The RPS FB-regulated data stream that each message would be sent at a predict interval with the deadline checking. Second, one of the slave devices was assumed to be fail, i.e., the algorithms NetCom_Read and NetCom_Write in RPS were needed to be updated with an alternative code. Then, the nonreal-time chan- nel would be applied for the code distribution, and based on it, the overall time for code reconguration could be calculated to evaluate the efciency of this IEC61499-based management framework for RPS FB. A TaskTable for the distributed test application was assumed in Table I before the test running. The master manager is num- bered as A1, the following A2i (i = 1, 2, 3) is to denote tasks in SlaveDevice1, A3i (i = 1, 2) represent the IO tasks in SlaveDe- vice2, and other tasks that are denoted by Ai (i = 4, 5, 6, 7) are assumed with a long period that could be considered as the new added periodic tasks that requires to be inserted in the schedul- ing table of master manager during the system running. A4A7 tasks are deployed in the SlaveDevice3 and SlaveDevice4 sep- arately and generate the increasing workload with the remote starting. Fig. 12 presents the message scheduling result that shows the performance of time triggered scheduling table. Fromthe packet list, it can be seen that our real-time scheduling algorithm was built on a UDP unicast protocol; the new tasks from the ports TABLE I TASKTABLE OF SLAVE NODES 4000, 5000, 6000, and 7000 can be inserted into the original scheduling sequence (port from 2000 to 3000) but brings some delays for the original tasks. The red dot denotes the interval of an issued message, the white dot indicated this message is delayed in the EC, and the black block represents the processing time of a task. However, the RPS will check this delay through comparing with the deadline (shown in Table I). Thus, the result in Fig. 12 shows that the reconguration of scheduling table is enough to get a new sending sequence, i.e., all the messages are scheduled before their deadline. There is no need for the code reconguration to replace the scheduling algorithm. Furthermore, a time cost test for code reconguration was de- ployed. Under the FBDK, in order to see the effect of new code, FBDK Editor has to be restated before the last modication will be run. Thus, only the static code reconguration is sup- ported in our test. During code reconguration, the failed slave device would receive the alternative .class le with the assump- tion that there is backup nonreal-time channel (TCP server in RMT_DEV) for the receiving of alternative code. Sometimes, a new dynamic link library containing the native methods is also needed to be reloaded into the target space if the hardware changes or receiving an unknown packet. Therefore, the time cost for reconguration can be calculated as T reconguartion = T generation +T distribution +T loading which consists of three parts: the code generation time in the Eclipse, the code distribution time as a non real-time task sched- uled by RPS, and the code loading time in the embedded device. The result is platform dependent and affected by various issues such as size of code le, efciency of compiler, congestion status of network, and processor capability. The accuracy of system clock in the measurement is 10 ms. Time cost of a code reconguration for NetCom_Read and Net- Com_Write algorithm (in CLL) is summarized in Table II. The execution time of code generation and loading process is notably 96% of the total execution time for reconguration, the former takes 25 s on the PC to prepare the new code, and the latter takes 5 s on the slave devices to launch a new communication protocol stack. These two processes are executed ofine (i.e., computed in an independent computing unit) without having impact on communication activities of the old protocol stack ZHOU et al.: MODEL-DRIVEN DEVELOPMENT OF RECONFIGURABLE PROTOCOL STACK 1451 Fig. 12. Message scheduling based on the algorithm EDF. TABLE II TIME COST FOR THE RECONFIGURATION OF CLL LAYER BLOCK (T: TIME COST; M: MEASUREMENT) during reconguration execution period. The distribution of the new code is scheduled as the nonreal-time trafc with assigning a xed time slice in each macro scheduling cycle. This way, its impact on the real-time trafc could be controlled at a low level. Thus, although the transmission delay is very small, the average value for the distribution time could reach 1295 ms, which is caused by the postponed sending in each scheduling cycle. VI. CONCLUSION The dramatic growth of NCS confronts designers with serious difculties of distributed infrastructure complexity, communi- cation environment heterogeneity, and control strategy incom- patibility. The standard IEC61499 can be available to meet these challenges of autonomous reconguration behavior. The contribution of this paper is to propose a method for the development of RPS for NCS. Within this method, the novel de- sign of RPS FB is given and the standard IEC614499 has been signed as the fundamental role to implement the code recon- guration in the RPS FB. Through extracting common features that contribute to the design of the recongurable protocol, and structuring a unied architecture that suggests a general guide- line on the internal and external information exchange, the pro- posed RPS FB runs beyond previous works. Furthermore, data interfaces and state machines are devised for the reconguration of application, network transmissions and CLLs. Different from the existing architectures in NCS, the routing and the scheduling schemes are highlighted as the core of protocol stack. Based on the IEC61499, the FBs for the reconguration com- munication service have been developed as the extension of service interface FBs of the tool FBDK. The future work will be on the verication of the presented concepts with the help of certain IEC61499 sample applications. Additionally, in the embedded environment of IEC61499, deeper investigations on a more compact runtime environment (e.g., 4DIAC) should be concerned for the running of RPS. REFERENCES [1] F. Wang, D. Liu, S. X. Yang, and L. Li, Networking, sensing, and control for networked control systems: Architectures, algorithms, and applica- tions, IEEE Trans. Syst. Man Cybern. C, Appl. Rev., vol. 37, no. 2, pp. 157159, Mar. 2007. [2] S. Kolla, D. Border, and E. Mayer, Fieldbus networks for control system implementations, in Proc. Electr. Insul. Conf. Electr. Manuf. Coil Winding Exhib., Indianapolis, IN, 2003, pp. 493498. [3] F. Xia, Z. Wang, and Y. Sun, Integrated computation, communication and control: Towards next revolution in information technology, in Proc. Int. Conf. Inf. Technol., Hyderabad, India, 2004, pp. 117125. [4] K. Ravindran, M. Rabby, and J. Wu, Protocol-level recongurations for autonomic management of distributed network services, in Proc. IFIP/IEEE Int. Symp. Integr. Netw. Manage. Workshops, New York, 2009, pp. 185192. [5] M. Niamanesh and R. Jalili, DRAPS: A framework for dynamic recon- gurable protocol stacks, J. Inf. Sci. Eng., vol. 25, no. 3, pp. 827841, 2009. [6] M. Muhugusa, G. Di Marzo, C. Tschudin, E. Solana, and J. Harms, Imple- mentation and interpretation of protocols in the ComScript environment, in Proc. IEEE Int. Conf. Commun., Seattle, WA, 1995, pp. 379384. 1452 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 [7] Y. A. Eracar and M. M. Kokar, An architecture for software that adapts to changes in requirements, J. Syst. Softw., vol. 50, no. 3, pp. 209219, 2000. [8] H. Chen, C. Zhou, and W. Zhu, Modelling the protocol stack in NCS with deterministic and stochastic petri net, Int. J. Sys. Sci., vol. 42, no. 6, pp. 10571064, 2011. [9] H. Chen, C. Zhou, X. Huang, Q. Yuan, and Y. Shi, Management of the recongurable protocol stack based on SDL for networked control systems, Inf. Technol. J., vol. 9, no. 5, pp. 849863, 2010. [10] J. Thomesse, Fieldbus technology in industrial automation, in Proc. IEEE, Jun. 2005, vol. 93, no. 6, pp. 10731101. [11] J. Decotignie, Ethernet-based real-time and industrial communications, Proc. IEEE, vol. 93, no. 6, pp. 11021117, Jun. 2005. [12] V. Vyatkin, H. M. Hanisch, P. Cheng, and Y. Chia-Han, Closed-loop modeling in future automation system engineering and validation, IEEE Trans. Syst. Man Cybern. C, Appl. Rev., vol. 39, no. 1, pp. 1728, Jan. 2009. [13] Di Marco, M. Caporuscio, and P. Inverardi, Model-based system recon- guration for dynamic performance management, J. Syst. Softw., vol. 80, no. 4, pp. 455473, 2007. [14] N. Vatanski, J. Georges, C. Aubrun, E. Rondeau, and S. Jamsa-Jounela, Networked control with delay measurement and estimation, Control Eng. Pract., vol. 17, no. 2, pp. 231244, 2009. [15] F. Lian, J. Moyne, and D. Tilbury, Network design consideration for distributed control systems, IEEE Trans. Control Syst. Technol., vol. 10, no. 2, pp. 297307, Mar. 2002. [16] D. Kim, D. Choi, and P. Mohapatra, Real-time scheduling method for networked discrete control systems, Control Eng. Pract., vol. 17, no. 5, pp. 564570, 2009. [17] C. Zhou, C. Xiang, H. Chen, and H. Fang, Genetic algorithm-based dynamic reconguration for networked control system, Neural Comput. Appl., vol. 17, no. 2, pp. 153160, 2008. [18] A. S. Denazis, S. Karnouskos, T. Suzuki, and S. Yoshizawa, Component- based execution environments of network elements and a protocol for their conguration, IEEE Trans. Syst. Man Cybern. C, Appl. Rev., vol. 34, no. 1, pp. 8296, Feb. 2004. [19] P. G. Bridges, G. T. Wong, M. Hiltunen, R. D. Schlichting, and M. J. Bar- rick, A congurable and extensible transport protocol, IEEE ACM Trans. Netw., vol. 15, no. 6, pp. 12541265, Dec. 2007. [20] International Electrotechnical Commission. (2005) IEC61499: Func- tion Blocks, Parts 14, International Standard/Technical Report, 1st ed. Geneva, Switzerland. [Online]. Available: http://www.fb61499. com/ [21] K. Thramboulidis, D. Perdikis, and S. Kantas, Model driven development of distributed control applications, Int. J. Adv. Manuf. Technol., vol. 33, no. 34, pp. 233242, 2007. [22] T. Strasser, A. Zoitl, F. Auinger, and C. Sunder, Towards engineering methods for reconguration of distributed real-time control systems based on the reference model of IEC61499, in Holonic and Multi-Agent Systems for Manufacturing (ser. Lect. Notes in Comput. Sci.). Berlin, Germany: Springer, 2005, pp. 165175. [23] C. Schwab, M. Tangermann, A. Luder, A. Kalogeras, and L. Ferrarini, Mapping of IEC61499 function blocks to automation protocols within the TORERO approach, in Proc. Int. Conf. Ind. Informat., Berlin, Germany, 2004, pp. 149154. [24] M. N. Rooker, C. Sunder, T. Strasser, A. Zoitl, O. Hummer, and G. Eben- hofer, Zero downtime reconguration of distributed automation systems: The CEDAC approach, in Proc. 3rd Int. Conf. Ind. Appl. Holonic Multi- Agent Syst., 2007, pp. 326337. [25] R. W. Brennan, M. Fletcher, and D. H. Norrie, An agent-based approach to reconguration of real-time distributed control systems, IEEE Trans. Robot. Autom., vol. 18, no. 4, pp. 444451, Aug. 2002. [26] F. Weehuizen and A. Zoitl, Using the CIP protocol with IEC61499 com- munication function blocks, in Proc. IEEE Int. Conf. Ind. Informat., Piscataway, NJ, 2007, pp. 261265. [27] M. Wenger, R. Froschauer, A. Zoitl, M. Rooker, G. Ebenhofer, and T. Strasser, Model-driven engineering of networked industrial automa- tion systems, in Proc. Int. Conf. Ind. Informat., Osaka, Japan, 2010, pp. 902907. [28] R. Froschauer, A. Schimmel, F. Auinger, and A. Zoitl, Engineering of communication links with AADL in IEC61499 automation and control systems, in Proc. Int. Conf. Ind. Informat., Cardiff, U.K, 2009, pp. 582 587. [29] A. Zoitl, G. Grabmair, F. Auinger, and C. Sunder, Executing real-time constrained controlapplications modeled in IEC6 with respect to dynamic reconguration, in Proc. Int. Conf. Ind. Informat., Perth, WA, Australia, 2005, pp. 149967. [30] HOLOBLOC Inc. (2008). FBDK: The Function Block Development Kit. [Online]. Available: http://www.holobloc.com [31] K. Thramboulidis, IEC61499 in factory automation, in Proc. Int. Conf. Ind. Electron. Technol. Automat., Bridgeport, CT, 2005, pp. 19. [32] F. Perez, D. Orive, M. Marcos, E. Estevez, G. Moran, and I. Calvo, Ac- cess to process data with OPC-DA using IEC6 service interface func- tion blocks, in Proc. IEEE Conf. Emerging Technol. Factory Automat., Mallorca, Spain, 2009, pp. 149916. [33] P. Pedreiras and L. Almeida, EDF message scheduling on controller area network, Comput. Control Eng. J., vol. 13, no. 4, pp. 163170, 2002. [34] R. W. Brennan, P. Vrba, P. Tichy, A. Zoitl, C. S under, T. Strasser, and V. Marik, Development in dynamic and intelligent reconguration of industrial automation, Comput. Ind., vol. 59, no. 6, pp. 533547, 2008. Chunjie Zhou was born in Hubei, China, in 1965. He received the M.S. and Ph.D. degrees in control theory and control engineering from the Huazhong Univer- sity of Science and Technology, Wuhan, China, in 1991 and 2001, respectively. He is currently a Doctoral Tutor Professor with the Department of Control Science and Engineering, Huazhong University of Science and Technology. His research interests include industrial communication, articial intelligent, and theory and application of networked control system. Hui Chen was born in Fujian, China, in 1982. He re- ceived the B.Sc. degree in electrical and electronics engineering from the University of Fuzhou, Fuzhou, China, in 2005, and the M.S. degree in control theory and control engineering from the Huazhong Univer- sity of Science and Technology, Wuhan, China, in 2007, under the supervision of Z. Chunjie, where he is currently working toward the Ph.D. degree in con- trol science and engineering. His research interests include formal description technology and industrial communication. Naixue Xiong (S07M08) received the Ph.D. de- grees in computer science from Wuhan University, Wuhan, China and Japan Advanced Institute of Sci- ence and Technology, Nomi, Japan, respectively. He is currently a Research Scientist with the De- partment of Computer Science, Georgia State Univer- sity, Atlanta. His research interests include commu- nication protocols, network architecture and design, and optimization theory. ZHOU et al.: MODEL-DRIVEN DEVELOPMENT OF RECONFIGURABLE PROTOCOL STACK 1453 Xiongfeng Huang was born in Hubei, China, in 1980. He received the B.S. degree in automation from the Wuhan University of Hydraulic and Electrical Engi- neering, Yichang, China, in 2002, and the M.S. degree in control theory and control engineering from China Three Gorges University, Yichang, China, in 2009. He is currently working toward the Ph.D. degree in control science and engineering with the Huazhong University of Science and Technology, Wuhan China. His research interests include industrial commu- nication and theory and application of networked control system. Athanasios V. Vasilakos (M95SM09) received the B.S. degree in electrical and computer engineer- ing from the University of Thrace, Xanthi, Greece, in 1983, the M.S. degree in computer engineering from the University of Massachusetts, Amherst, in 1986, and the Ph.D. degree in computer engineering from the University of Patras, Patras, Greece, in 1988. He is currently a Professor with the Department of Computer and Telecommunications Engineering, University of Western Macedonia, Kozani, Greece, and a Visiting Professor in the Graduate Programme of the Department of Electrical and Computer Engineering, National Technical University of Athens, Athens, Greece. He has authored or coauthored more than 200 technical papers in major international journals and conferences. He is also the author or coauthor of ve books and 20 book chapters in the areas of communications. Prof. Vasilakos was the General Chair, the TPC Chair, and the Symposium Chair for many international conferences. He was or has been the Editor or/and Guest Editor for many technical journals, such as the IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICSPART B: CYBERNETICS, the IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, THE IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, and ACM Transactions on Autonomous and Adaptive Systems. He is the Founding Editor-in-Chief of the International Journal of Adaptive and Autonomous Communications Systems and International Journal of Arts and Technolog. He is the Chairman of the Intelligent Systems Applications Technical Committee of the IEEE Computa- tional Intelligence Society.