Model-Driven Development of Reconfigurable Protocol Stack for Networked Control Systems

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 42, NO. 6, NOVEMBER 2012 1439

Model-Driven Development of ReconfigurableProtocol Stack for Networked Control Systems

Chunjie Zhou, Hui Chen, Naixue Xiong, Member, IEEE, Xiongfeng Huang,and Athanasios V. Vasilakos, Senior Member, IEEE

Abstract—In networked control systems (NCS), the performancedegradation introduced by the heterogeneous and dynamic envi-ronment has intensified the need for reconfigurable protocol stacks(RPS). In this paper, an IEC61499-based method is proposed forthe model-driven development of RPS. The method is enabled bydefining a novel RPS function block (FB), which unifies the commu-nication behavior and interface of nodes in NCS. Beyond existingcommunication FBs in IEC61499, the parameter reconfigurationof routing and scheduling table in RPS FB is highlighted as thecore of communication layer function to adapt environment andsystem variations. Furthermore, the method allows for the codereconfiguration on Java algorithms in RPS FB under different ap-plication requirements. Through porting the Java virtual machineon different platforms, the code reconfiguration is implemented byreloading the .class file for a specified protocol FB. A case studyon the embedded platform, such as DSP/BIOS and ARM/Linux,is conducted to demonstrate the effectiveness and feasibility ofthe proposed reconfiguration method for maintaining stable andpredictable behavior in NCS.

Index Terms—IEC61499, model-driven development, net-worked control system (NCS), protocol stack, reconfiguration.

I. INTRODUCTION

ANETWORKED control system (NCS) uses a distributedcontrol architecture where sensors, actuators, and con-

trollers are interconnected through a real-time network [1]. Thecommunication protocol stack that directly affects the perceivedcommunication quality of service (QoS) plays a critical role indetermining the system performance. However, a unified com-munication protocol standard is not available at present for thereasons of commercial benefits, history, and multiapplicationobjects [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; acceptedFebruary 28, 2012. Date of publication May 1, 2012; date of current versionDecember 17, 2012. This work was supported in part by the National NaturalScience Foundation of China under Grant 61074145 and Grant 60674081. Thispaper 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, Departmentof Control Science and Engineering, Huazhong University of Science andTechnology, Wuhan 430074, China (e-mail: [email protected]; [email protected]; [email protected]).

N. Xiong is with the Department of Computer Science, Georgia State Uni-versity, Atlanta, GA 30303 USA (e-mail: [email protected]).

A. V. Vasilakos is with the Department of Computer and TelecommunicationsEngineering, University of Western Macedonia, 50100 Kozani, Greece (e-mail:[email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TSMCC.2012.2190593

application demands, or the network disturbance. Consequently,the control algorithm in the system will not render the intendedresults if certain QoS conditions (e.g., time delay) are not ob-served. It is inherently difficult to guarantee punctuality andpredictable QoS, because QoS objects of different protocols arehard to be coordinated in a whole when lacking of a unifiedarchitecture that specifies functional and interactions modelstherein.

To cope with this challenge, there has been an increasingemphasis on developing reconfigurable protocol stacks (RPS)in such a distributed, heterogeneous, and changeable environ-ment [4], [5]. Protocol stack reconfiguration is the implementa-tion of a software environment that supports flexible manage-ment of protocol components. Reconfiguration behaviors, suchas parameter reassignment, service updating, and functionalityreplacement, will be executed once the environment constraintsor system requirements change.

Traditionally, most reconfiguration approaches enumeratedall possible strategies that were in general coded of devices,such as the “ComScript environment” represented by Muhugusaet al. [6] and the “feedback control framework” by Eracar andKokar [7]. Current software engineering such as model-drivendevelopment can facilitate the development and deployment ofcomplex protocol reconfiguration process. Motivated by theseresearch works, we proposed architectures for the functionalityverification and performance evaluation of RPS for NCS [8], [9].The reconfiguration 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. Thestandard IEC61499 has addressed these issues, which providesseamless interface for IEC61131-3 applications and could beregarded as a model-driven development approach for the rapiddeployment of real-time distributed automation systems. Thereconfiguration that is defined by IEC61499 could be automaticwithout service interruption or with a minimal one [12], [13].

In this paper, we develop a model-driven framework to im-plement a reconfiguration scheme for protocol stacks of NCS.The standard IEC61499 is used to build FBs representing differ-ent protocol algorithms and interfaces. These protocol FBs arecomposed to be a unified RPS composite FB, which providesa unified architecture for industrial communication and dealswith the heterogeneous and dynamic environment by inherit-ing the advantages of Java and IEC61131-3. Both parameterand code reconfiguration are enabled with the help of FunctionBlock Development Kit (FBDK), which is the one of famous

1094-6977/$31.00 © 2012 IEEE

1440 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART 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 theQoS control are highlighted as the core of RPS architecture. Inthis cross-layer way, the RPS can reconfigure the parametersof routing and scheduling table at run time to cope with varia-tions from the application, data link, and physical layer. On theother hand, the RPS FB is distributed to different devices withFunction Block Runtime (FBRT) environment, which is a jarfile providing methods for the running of FBs defined in FBDK.The platform heterogeneous problem has been solved by port-ing of JVM. The code reconfiguration is enabled by replacingand recompiling the .class file of a certain protocol FB.

The remainder of this paper is organized as follows. SectionII investigates the background of our work, including charac-teristics of NCS, practices of protocol stack architecture, andreconfiguration researches in IEC61499. Section III elaboratesthe framework for the model-driven management of RPS forNCS. In Section IV, a set of FBs and detail data interfaces aredevised for the information exchange architecture of protocolstack under the standard of IEC61499. In Section V, a test ap-plication for the proposed RPS FB is built up, and the real-timescheduling and reconfiguration test are conducted to show howthe RPS works and how the real-time performance has beenguaranteed. Finally, Section VI gives concluding remarks andfuture topics.

II. RELATED WORK

In this section, we discuss the existing subproblems of re-configuration design in terms of communication characteristicsover NCS, reconfiguration methods, and the standard IEC61499for dynamic reconfigurations.

An NCS is a distributed real-time control system (see Fig. 1).In order to alleviate network loads on one shared medium, thecontrol network that connects field devices is usually dividedinto a number of network segments with different applicationobjects. One master node is defined to govern the messagescheduling of inner segment and dynamic connections to outersegment, while other slave nodes act as functional nodes ofsensor, controller, and actuator which occupy communicationresources 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 suchas delays, jitters, packet losses, and link failures [14]. All thereal-time data transmissions meet the delay bound is the mostimportant performance indicator for NCS. In order to assuregood performance, the time delay from sensor to controller, orcontroller to actuator, should be controlled in a certain range bycommunication protocols. If the controller does not receive anyresponse before the deadline, the control performance would bedegraded [15]. More specifically, the time delay is composed offour parts: the sending, waiting, receiving, and transmission de-lays. The sending and receiving time delays are divinable whenthe computation capability and the standard of message handlingprocess are determined on a specific platform. Comparatively,the waiting and transmission time delays are undeterministic,which depend on the communication environment (e.g., trafficload, bandwidth, and transmission paths) and the way to sharecommunication resources. All these time issues are highly in-fluenced by the software architecture design of communicationprotocol stack.

In order to realize the RPS supporting many different kindsof critical real-time applications and network protocols in NCS,the following two fundamental problems have to be studied.

The first consideration is to characterize and model the systemstructure, traffic classification, 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 differentprotocol standards. These general modules are formed togetheras the backbone of protocol stack, and they would perform anew function that adapts to variegations in requirements whenbeing recognized. Motivated by these, we attempt to provide aunified framework for the support of reconfiguration manage-ment to accommodate heterogeneous protocol standards anddifferent 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 thewaiting time delay [16], and the routing scheme that governs thetransmission paths and network topology determine the trans-mission time delay [17]. Thus, these two QoS related schemesshould be highlighted as the core of protocol stack.

The second problem is the question of how to design a datainterface with real-time features and to provide a real-time in-tertask communication channel that concurrently carries inter-reconfiguration jobs between protocol modules. An explicitspecification is needed for the real-time processing both insideand outside protocol stack at the level of data frame structureamong software modules. In the communication community,the heterogeneous standards and the changeable environmenthave both intensified the protocol stack to be capable of thereconfiguration ability. Researchers in networking communityhad begun to pay more efforts on the design of RPS since the1990s [6]. The work of Muhugusa et al. [6] presented a hierar-chical framework to construct adaptive protocol stacks by thereplacement of an entire protocol stack with a new one. Eracarand Kokar [7] implemented the reconfigurable 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 moduleswas given in the work of Denazis et al. [18] and Bridges et al.[19], which supported a framework to construct configurableprotocol 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 reconfiguration 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 event–driven executionmodel, a management interface capable of basic reconfigurationsupport, and the application centered engineering methodology[22]. Various researchers developed reconfiguration methodolo-gies for the industrial communication based on IEC61499: Theresearch project TORERO [23] focused on plug-and-play andself-(re)configuration of field 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 tothe devices. Rooker et al. [24] discussed the dynamic reconfig-uration management method “zero downtime reconfiguration”for downtimeless system evolution of control applications onbasis of the standard IEC61499. Brennan et al. [25] exploitedmultiagent techniques to allow the system to reconfigure au-tomatically in response to change. In general, these analysesare based on specific logic formalizations and applied in thereconfiguration of system components, but not for the protocolreconfiguration that affected the networking performance of adistributed 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 supportingreal-time constrained execution within an IEC 64199 device.Froschauer et al. [28] cover the modeling frameworks for thediverse communication links with different protocols and QoSconstraints and used the architecture analysis and design lan-guage (AADL) to extend the IEC61499 modeling ability onthe QoS definition and validation. In [29], the authors appliedthe integration of the AADL Software model and the FDCMLHardware model to reduce the engineering time by an automaticconfiguration of the communication networks. Similar to theseworks, we use a pure IEC61499 framework to give a genetic RPSFB for distributed automation systems. The RPS framework isfocused on providing the real-time communication services withthe routing and scheduling algorithm inside protocol algorithm,rather than the executions between FBs. Based on the RPSframework, parameter reconfiguration and code reconfigurationare supported by the IEC61499 environment, such as FBDK.

The tool FBDK can supports the whole reconfiguration lifecycle [30]. It is capable of defining FB types, and designingFB diagrams, resources, and devices, as well as provides aJava interface that lets the engineer to visually test his dia-grams. Similarly, the project FBRT and Archimedes SystemPlatform [31] also made big efforts on the issue of generation ofexecutable code from FB design specifications. However, it isimportant to note that the RPS framework is not limited to any

IEC61499 development tools. Our reconfiguration idea of proto-col stack is shown by explicating a set of IEC61499 componentsand interfaces to accommodate different protocol standards,rather than relying on a fixed repository of predefined protocolconfigurations.

III. RECONFIGURATION MANAGEMENT OF RECONFIGURABLE

PROTOCOL STACK FUNCTION BLOCK

RPS requires software architectures that are flexible and cansupport tools and algorithms from a variety of sources and do-mains. The management is the key to implement the RPS. Itallows applications to dynamically adjust the parameters config-uration of each layer or mix and match protocol FBs accordingto control requirements and network availability. This sectionintroduces a model-driven framework realizing the reconfigura-tion management process of the code and model space on basisof the information exchange architecture of RPS.

A. Management Structure

A management structure is devised to control the reconfigu-ration procedures of protocol stack that reacts to changes in thenetwork and user environment. Fig. 2 outlines the reconfigura-tion management framework that serves as a general workflowto deal with the interaction between individuals and coordina-tion with environment during the reconfiguration process. Theframework manages the parameter reconfiguration and codereconfiguration with processes of model description, code vali-dation, performance evaluation, and algorithm optimization.

1) Model Description: Benefiting from the IEC61499, allstructural, functional, and data aspects of the protocolstack could be added to composite IEC61499 FBs. TheIEC61499 is taken as the basis of our model-driven devel-opment technique that keeps track of data flows, identifiesthe type of changes, evaluates the reconfiguration result,and generates a new stack code accordingly.

2) Code Validation: With the help of JAVA, our proposedframework for the implementation of RPS could detectthe functional inconsistency or errors with controller de-mands. Once the validation passed, the new protocol FBcould be porting to different environment.

3) Performance Evaluation: The given protocol stack FBswould be deployed in a specified system scenario. Giventhe set of architecture and environment blocks defined forthe system, the execution of protocol stack is influencedby the aspects of computation ability, resource availability,and transmission time delay. Then, evaluation results, e.g.,delay constraint, network utilization, and efficiency, arecompared.

4) Algorithm Optimization: In the case of communicationperformance not satisfying with the control requirements,the parameter configuration inside the protocol FB wouldbe first acted on the changes in routing and schedulingtable to adapt the environments variations. Otherwise, ifthe system or environment changes severely, e.g., new ap-plications or new hardware platform is required, the codereconfiguration is performed as the procedure of algorithm


Fig. 2. IEC61499-based reconfiguration management framework.

optimization by fetching a new protocol file (defined asthe .class file) from the block library to replace the oldone and enhance the related protocol functionality. Thenew protocol files are packeted and physically transportedover network. In this manner, the core reconfigurationmechanisms, routing and scheduling procedure, are fun-damentally changed to provide a more intelligent rule todeal with the new task sets or link conditions. For exam-ple, the rate monotonic (RM) algorithm would be goodat the low network load, but with the increasing work-load, the early deadline first (EDF) algorithm could beseemed as an option of optimized scheduling algorithms.Moreover, master/slave polling is required in some strictlyconditions to guarantee a deterministic delay. Besides, thisIEC61499 compliant framework should maintain the con-struction consistency among the (new) performance modeland the system configuration.

B. Architecture of the Protocol Stack

The layered protocol stack usually consists of five layers:physical, data link, network, transport, and application layer(APP) with reference to the open systems interconnectionmodel. Motivated by the existing layering architectures [10],[11], protocol functionality and layer compositions are recon-

structed to better sever the reconfiguration viewpoint, whichconsists of the communication link layer (CLL), the networktransmission layer (NTL), and the APP. This new architectureemphasizes on utilizing cross-layer information to constrain theworking of reconfigurable routing and scheduling scheme. Thearchitecture 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 protocollayers. The characteristics of RPS could be described from threeaspects: working mode, routing, and scheduling.

1) Reconfiguration of Working Mode: Commonly opera-tion mode and fault mode are the two basic working modesof media access control (MAC), except for the configurationmode. 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 resultof neighbor nodes (normal or abnormal). Once an error hap-pens, it will be recorded in the sending or receiving vectorof MAC controller and issues an interrupt signal from theMAC controller to the CPU. After that, protocol data unit ana-lyzer checks the fault type and starts the Interrupt Manager toswitch the working mode of MAC controller from the normal


Fig. 3. Architecture of RPS.

operation to the fault mode. The reconfiguration of workingmode is to guarantee that the fault node does not interferewith the working of others until it become normal again. TheIEC61499 framework implements a set of hardware drivers oroperating system application program interfaces (OS APIs) call-ing methods for this working mode reconfiguration in CLL.

2) Reconfiguration of Routing Table: The topology structurein the open-network control systems is always heterogeneousand changeable. When new devices or tasks are added to thesystem or someone is out of work, the topology of the NCSwould be changed; then, the routing tables distributed in themaster nodes are required to be reconfigured to update network-ing paths for such a new data transmission requirement. Other-wise, the QoS value (e.g., the transmission delay) may increaseor decrease unpredictably and leads to performance decreas-ing. The routing reconfiguration of NCS is a very complicatedcombinatorial optimization problem, which can be similar tothe NP-complete problem, such as bottleneck traveling sales-man problem. Thus, some intelligent algorithms are required toimprove the searching ability for the complex solution space.In the previous work [17], an improved mechanism based ongenetic algorithm was designed to find the minimum time-delaypath for the routing table reconfiguration.

3) Reconfiguration of Scheduling Table: The problem ofnetwork scheduling in NCS is to assign a transmission table

(in master nodes) for each message (issued by the nonperiodicand periodic tasks in slave nodes) on the shared communica-tion media according to the scheduling algorithms (a set oftime and event triggered rules that determine the order in whichmessages are transmitted). Based on the QoS, the parameters ofscheduling algorithms, such as bandwidths for the periodic tasksand the nonperiodic tasks, the polled sequence of slave nodes,and the length of a time slice, will be reconfigured accordinglyto renew the transmission table (i.e., scheduling table). In theIEC61499 modeling framework, the scheduling procedure isdefined as a protocol algorithm in the NTL, which calculatesa new scheduling sequence (stored in a table) for the remoteoperations between the master and slave devices. The algorithmis imitated by the task information of system and triggered bythe QoS_Change event and the scheduling table will be updatedat 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 theinternal information architecture according to the model-drivendevelopment standard IEC61499. The major advantage of the


Fig. 4. Composite FB of RPS.

IEC61499 architecture is that it addresses the higher levelaspects of communication, cooperation, and decision makingamong nodes of NCS. Details on how the IEC61499 supportsreconfiguration management and distributed communication arefully discussed in [21], and [25]–[29]. Here, we focus on ex-tending subscribe/publish service (i.e., user datagram protocol(UDP) socket) with a reconfiguration support for communica-tion activities among control applications. This enhanced com-munication service block is an integrated resource model thatconsists of three basic blocks for the layer specifications ofRPS.

A. Modeling the Reconfigurable Protocol Stack

The model for the architecture of RPS is depicted in Fig. 4,which is mapping from the interface and workflow of Fig. 3. Themodel is considered as a composite FB that provides three kindsof protocol services: sending, receiving, and reconfiguration.

Before the running of RPS FB, the initialization of input(INTI) and initialization of output (INTO) events are used toinitialize the node platform resources (e.g., CPU, primary andsecondary 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 serviceis accessed by the user program that could be any type of re-mote control applications, which is controlled by the event flow“Send_REQ → FromAPP_REQ → NTL_REQ,” and generat-ing the data flow “User_Task→APP_data→NTL_Packet.” Onthe side of receiving service, another FB execution flow startingfrom the CLL layer is required. The transmission control algo-rithms in NTL are triggered by the complement confirmation offrame receiving (Net_CNF). Then, the user program begins toreceive the data once receiving the request event (APP_REQ),which represents that the process for decoding and queuingNTL_Packet has been done. The complement of receiving ser-vice is denoted by the event APP_CNF.

The parameter reconfiguration service that is defined in therouting and scheduling algorithm in NTL is triggered by moni-toring the QoS information (QoS_Change) that contained in thereceiving CLL frame. The request event for NTL_Packet rerout-

ing (ReRoute_REQ) is triggered in the case that the end-to-enddelay violates deadline due to the performance degradation ofone of the router devices in the original path. The request eventfor the rescheduling of APP message (ReSch_REQ) is trig-gered on the situation that the workload on sharing resources isincreased suddenly with a slave nodes added in. The new nodewill lead to CLL frames appearing on a new port.

In this RPS FB, all the protocol algorithms are implementedin the JAVA language and apply the Java Native Interface (JNI)method. The JNI can interact with other programs written inother languages such as C, C++, and assembly in .class filesfor the fulfilling of these RSP services [32].

The APP block is the interface between the protocol stackand users to collect the node information and interpret theUser_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. Thechange of system structure or task requirements would transferthrough the data channels of “Node_Info ↔ TaskTable” and“Sys_Info ↔ TopoStructure,” which reinitialize the configura-tion of platform resources that are required by the schedulingand routing algorithm of NTL.

The NTL block is mainly composed of three parts: the datachannel, the scheduling scheme, and the routing scheme. Thescheduling scheme is to assign a time table determining thesending intervals for each transmission entity, both nonperi-odic and periodic tasks. The scheduling table is constructed asa specific string format, which is broadcast to the subscribeddevices to control the traffic between the APP and NTL. Therouting scheme can provide the QoS-guaranteed end-to-end datalink service for the scheduling scheme. It determines the nexthop address in the NTL_Packet forwarding with the assump-tion that transmission delays are all bounded into a certainrange.

The CLL mainly represents the functionalities of physicallayer and the data link layer. In common, they are integrated ina special-purpose chip. Thus, the CLL is the emphasis of hard-ware reconfiguration that is concerning the appropriate param-eter configuration on the hardware chip. The port QoS_Changeis to report the peer-to-peer link status.


Fig. 5. FB of APP. (a) Interface. (b) ECC.

B. Protocol Stack Components

The RPS FB is to provide the communication service for theremote tasks, and the APP layer block is the interface for theuser FBs. Then, the application data are then coded into thepayload of routing protocols and the traffic flow is controlledby the scheduling scheme. The scheduling process is relied onthe reconfiguration of NTL. In other words, the reconfigura-tion of NTL is processing the algorithms of topology control,scheduling, and routing. The CLL is concerning the appropriateparameter configuration on the working mode of the hardwarechip.

1) Application layer: The APP is to represent informationof node and system, message coding and decoding for a specifictask, and the queue management of User_Tasks. As depicted inFig. 5, the initial state of START is to indicate that the protocolstack is ready for providing communication service. The otherstates in the execution control chart (ECC) can be described asfollows.

a) INIT: It is the initialization state to prepare the informationof TaskTable and topology structure for reconfigurationactivities.

b) Q_Operation & TaskClassfication: They are the states thatrepresent the queuing of nonperiodic and periodic tasks.In order to avoid the task stack overflow, both sending andreceiving queues are needed to represent the processingcapability of RPS FB. The algorithm Q_Operation con-tains the PUSH, POP, and Resort operations for the queuemanage. After the state of TaskClassification, the peri-odic and nonperiodic task’s PUSH operation is distinct,i.e., the former is performed according to time triggertable (the rescheduling result) and the latter is inserted in

queue with high priority received during a nonperiodic taskdeclaration. On the message-receiving side, the algorithmDCodeUserTask abstracts the user data from the NTL andanalyzes the network status report that is contained in thisNTL_message to decide whether to accept the receivinguser 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_Tasksand NTL_Packet. The state SendToNTL is the filling ofuser data into an NTL_Packet, while the SendToUser isto analyze the NTL report to deliver required data to thecorresponding User_Tasks.

2) Network Transmission Layer: NTL is to provide a QoSguaranteed scheme for the stabilization of environments varia-tion and optimization of control performance (see Fig. 6). Thestates that are defined in ECC could be classified into three cat-egories: the message channel, the rerouting mechanism, and therescheduling mechanism.

a) SEND & RECEIVE: One important function of thesetwo states is the coding/decoding of data frame with differ-ent transmission protocols. On receiving the request eventFromAPP_REQ, the Packet head is written before the stringof APP_Data to form a specified network packet for networktransmission, for example, the packet head could be IP headhere. On the other hand, each frame receiving from the CLL isdecoded in the algorithm DCodeCLL_Frame to identify whichchannel it belongs to.

b) TransControl: It is the state that is under the controlof scheduling signals. It comprises two processes: one is for


Fig. 6. FB of NTL. (a) Interface. (b) ECC.

real-time traffic–real-time (RT) channel, the other is for nonreal-time traffic–nonreal-time (NRT) channel. The RT channel onlyimplements the necessary functionality of packet assemblingor 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 bothalgorithms of RT_Channel and NRT_Channel is used to decidethe event FromCLL_CNF that informs the APP block that anew NTL_message is ready. The outdated message would bediscarded.

c) ReRouting: This state is the kernel of routing recon-figuration, which is followed by the missing or failure result inthe state PathQuery and determines the next hop address for thestate forwarding. The received message will be forwarded to theCLL directly by the algorithm UniCast on the case that the des-tination is in the same network segment; otherwise, it will findthe next hop address in the neighbored segments. Fig. 7 showsthe workflow of algorithm SPF (Shortest Path First) for the stateReRouting. SPF is responsible for updating the next hop addressinformation in the routing table when the cost of old routing pathis out of the delay bounds. The SPF is a graph search algorithmthat solves the single-source shortest path problem for a graphwith nonnegative edge path costs, producing a shortest path tree,and the tree is distributed into the next hop information for thepacket forwarding. The tree of forming SPF is based on theservice of topology control. The changing of topology graphwill affect the vector to perform the SPF algorithm. Thus, the

parameter of SPF could be changed in QoS or system informa-tion, and, finally, the SPF can calculate a new address parameterfor the routing table. Moreover, for our IEC61499-based RPSframework, the SPF algorithm would be easily updated by otherswhen the problem is more complex and the searching efficiencydoes not fulfill the real-time requirement.

Once a transmission request appears on the NTL, the routingframe is formed with a general data structure as “Preamble |SFD | Destination Address | Source Address | Protocol Type |Data | Padding | FCS.” All the referring segments should followa certain communication standard, for instance, the IEEE 802.3for Ethernet. In addition, depended on different QoS levels, the“Data” field could be varied from different routing service.

d) ReScheduling: This state activates QoS_changes inCLL that trigger the event ReSch_REQ. Then, the stateReScheduling will recalculate the scheduling table with an algo-rithm for the arrangement of sending intervals of messages. Thescheduling message (SchMSG) is generated in the state of syn-chronous transmission (SynTransmission) and asynchronouspolling (AsynPolling). The data structure for TaskTable andscheduling table (i.e., SchMSG frame) is shown in Fig. 8. First,the transmission sequence of message task is determined byan algorithm like EDF. Specifically, such a flexible data struc-ture is derived from the work of Pedreiras and Almeida [33],which efficiently supports hard-real-time operation in a flexibleway, seamlessly over shared or switched Ethernet. Similar tothe ReRouting state, the algorithm in the state ReScheduling


Fig. 7. Data interface for the routing reconfiguration.

Fig. 8. Data interface for the scheduling reconfiguration.

could be reconfigured 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. Weconsidered the reconfiguration of algorithm replacement on theassumption that the required resources do not exceed the the-oretical maximum workload on a sharing media. Second, thescheduling table is formed as a set of element cycles (EC) thatrepresent the traffic within a certain period. The size of eachscheduling table should be equal to a macro cycle, which com-prises enough ECs for polling all the tasks of slaves once analgorithm Assemble_Sch_Frame uses the task sequence of eachEC line to assemble SchMSG, which is broadcasted from themaster node and allocates a time slice for the task in each slave.The parameter reconfiguration of scheduling table is in a styleof plan to plan, i.e., replaces the old SchMSG with a new table

in data filed to cope with possible changes in the task set andthe variation of QoS.

3) Communication Link Layer: CLL is to provide a reliablepeer-to-peer link (see Fig. 9). The ECC that is depicted in Fig. 9shows the switching between the mode of normal operation andfault processing for hardware configuration.

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 intocommunication controller (a hardware device). The pro-cess of CheckLinkStatus can issue an event QoS_Changeto announce for the scheduling reconfiguration inNTL.


Fig. 9. FB of CLL. (a) Interface. (b) ECC.

b) Fault: It is the state for the fault processing that could beactivated by the confirmation of routing reconfiguration.The fault may be of two types: one is caused by the conflictand the other is referred to the link error. For the former,the algorithm BackoffAndRetry will start a random delaytimer for the resending of blocked frames. Meanwhile,the algorithm CheckLinkStatus is used to match the errorcode provided by hardware APIs. Once the link error isidentified, correcting operations will take a while beforeswitching back to the idle state and may issue the eventQoS_Change to inform the NTL the loss of neighbor nodewhen the error counter exceeds a certain default value.

c) TimeSynchronous: The algorithm TimeSynCal for thisstate is used to maintain a global clock for all master andslave nodes in one network segment. Based on the globalclock, the TimeSynCal implements the precise calculationof QoS value (time delay) for the ReRouting process inNTL.

V. CASE STUDY

This section focuses on the reconfiguration process in moredetails. In the shop floor of NCS, various real-time mechatronicsystems exist in the form of embedded controllers, industrialPCs, and programmable controllers [34]. Under this concept,we used the model-driven development environment FBDK toprototype 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 codereconfiguration.

A. Test System Configuration

A test application for the RPS FB is given in Fig. 10, whichis a bus communication system containing two device types:the master manager and the slave device. It is typical networkarchitecture for NCS, for example, the DeviceNet defined by theROCKWELL Crop. In this architecture, the application methodof RPS FB is similar to the mechanism of Publish/Subscribemodel in the library of FBDK, not only providing a UDP con-nection service, but also encapsulating the algorithm for theguarantee of real-time performance through parameter reconfig-uration. Of course, the code level reconfiguration is supported,i.e., RPS FB can adapt its communication service for differentbus protocol applications by reloading a .class file for the Javanative implementation.

In detail, the master manager is responsible for schedul-ing message transmissions in the segment, collecting the datafrom slave devices using the Ethernet frame and capturing theQoS_Change events to perform the reconfiguration service onthe routing and scheduling table. In this case, each slave deviceperiodically generates data to the master, and the master displaysthe receiving results. Within the master, UserCTL is the controlpanel to display the slave data, and in the display, a special FBto access the .txt file is developed to record packet and interfacewith a third part data analysis tool. The scheduling algorithmin RPS can coordinate different periodic tasks in a nonconflictway to avoid the delay variations. The routing algorithm just


Fig. 10. Test application for the RPS FB.

performed the role of discovering a new device added in andassigning its IP address in the table of master device, since therouter device is not used in this case study. As for the slavedevices, the basic RMT_DEV is introduced with the RPS FB toimprove UDP services.

The hardware platform for running the test application isgiven in Fig. 11. The application configuration file 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 andrunning on different embedded platforms, such as ARM/Linux(S3C2440) and DSP/BIOS (TMS320C55xx). The JVM versionfor 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) isused, and a method isEmpty() is demanded in the String.javabefore compiling this compact set. Thus, space requirementsfor 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/


Fig. 11. Hardware platform of the test system.

classes.zip:/home/classpath/share/classpath/glibj.zip#./../jamvm/bin/jamvm -classpath lib:fbrt.jarfb.rt.RMT_DEV -p events:ita:mach:net -s 1234

B. Experiment Results

Under experimental system setting, the performance on pa-rameter reconfiguration and code reconfiguration could be eval-uated. First, for the parameter reconfiguration test, we initializedthe system information that only contains the tasks in SlaveDe-vice1 and SlaveDevice2, and then, increased system tasks bystarting the other slaves during runtime. This way, we couldfind the reconfiguration result of scheduling table, i.e., the in-sertion of new tasks into the original task sequence. The RPSFB-regulated data stream that each message would be sent ata predict interval with the deadline checking. Second, one ofthe slave devices was assumed to be fail, i.e., the algorithmsNetCom_Read and NetCom_Write in RPS were needed to beupdated with an alternative code. Then, the nonreal-time chan-nel would be applied for the code distribution, and based onit, the overall time for code reconfiguration could be calculatedto evaluate the efficiency of this IEC61499-based managementframework for RPS FB.

A TaskTable for the distributed test application was assumedin 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 inSlaveDevice1, A3i (i = 1, 2) represent the IO tasks in SlaveDe-vice2, and other tasks that are denoted by Ai (i = 4, 5, 6, 7) areassumed with a long period that could be considered as the newadded periodic tasks that requires to be inserted in the schedul-ing table of master manager during the system running. A4–A7tasks are deployed in the SlaveDevice3 and SlaveDevice4 sep-arately and generate the increasing workload with the remotestarting.

Fig. 12 presents the message scheduling result that shows theperformance of time triggered scheduling table. From the packetlist, it can be seen that our real-time scheduling algorithm wasbuilt on a UDP unicast protocol; the new tasks from the ports

TABLE ITASKTABLE OF SLAVE NODES

4000, 5000, 6000, and 7000 can be inserted into the originalscheduling sequence (port from 2000 to 3000) but brings somedelays for the original tasks. The red dot denotes the intervalof an issued message, the white dot indicated this message isdelayed in the EC, and the black block represents the processingtime of a task. However, the RPS will check this delay throughcomparing with the deadline (shown in Table I). Thus, the resultin Fig. 12 shows that the reconfiguration of scheduling table isenough to get a new sending sequence, i.e., all the messages arescheduled before their deadline. There is no need for the codereconfiguration to replace the scheduling algorithm.

Furthermore, a time cost test for code reconfiguration was de-ployed. Under the FBDK, in order to see the effect of new code,FBDK Editor has to be restated before the last modificationwill be run. Thus, only the static code reconfiguration is sup-ported in our test. During code reconfiguration, the failed slavedevice would receive the alternative .class file with the assump-tion that there is backup nonreal-time channel (TCP server inRMT_DEV) for the receiving of alternative code. Sometimes,a new dynamic link library containing the native methods isalso needed to be reloaded into the target space if the hardwarechanges or receiving an unknown packet. Therefore, the timecost for reconfiguration can be calculated as

Treconfiguartion = Tgeneration + Tdistribution + Tloading

which consists of three parts: the code generation time in theEclipse, 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 issuessuch as size of code file, efficiency of compiler, congestion statusof network, and processor capability.

The accuracy of system clock in the measurement is 10 ms.Time cost of a code reconfiguration for NetCom_Read and Net-Com_Write algorithm (in CLL) is summarized in Table II. Theexecution time of code generation and loading process is notably96% of the total execution time for reconfiguration, the formertakes 25 s on the PC to prepare the new code, and the lattertakes 5 s on the slave devices to launch a new communicationprotocol stack. These two processes are executed offline (i.e.,computed in an independent computing unit) without havingimpact on communication activities of the old protocol stack


Fig. 12. Message scheduling based on the algorithm EDF.

TABLE IITIME COST FOR THE RECONFIGURATION OF CLL LAYER BLOCK

(T: TIME COST; M: MEASUREMENT)

during reconfiguration execution period. The distribution of thenew code is scheduled as the nonreal-time traffic with assigninga fixed time slice in each macro scheduling cycle. This way, itsimpact on the real-time traffic could be controlled at a low level.Thus, although the transmission delay is very small, the averagevalue for the distribution time could reach 1295 ms, which iscaused by the postponed sending in each scheduling cycle.

VI. CONCLUSION

The dramatic growth of NCS confronts designers with seriousdifficulties of distributed infrastructure complexity, communi-cation environment heterogeneity, and control strategy incom-patibility. The standard IEC61499 can be available to meet thesechallenges of autonomous reconfiguration behavior.

The contribution of this paper is to propose a method for thedevelopment of RPS for NCS. Within this method, the novel de-sign of RPS FB is given and the standard IEC614499 has beensigned as the fundamental role to implement the code recon-figuration in the RPS FB. Through extracting common featuresthat contribute to the design of the reconfigurable protocol, andstructuring a unified architecture that suggests a general guide-

line on the internal and external information exchange, the pro-posed RPS FB runs beyond previous works. Furthermore, datainterfaces and state machines are devised for the reconfigurationof application, network transmissions and CLLs. Different fromthe existing architectures in NCS, the routing and the schedulingschemes are highlighted as the core of protocol stack.

Based on the IEC61499, the FBs for the reconfiguration com-munication service have been developed as the extension ofservice interface FBs of the tool FBDK. The future work willbe on the verification of the presented concepts with the helpof certain IEC61499 sample applications. Additionally, in theembedded environment of IEC61499, deeper investigations ona more compact runtime environment (e.g., 4DIAC) should beconcerned for the running of RPS.

REFERENCES

[1] F. Wang, D. Liu, S. X. Yang, and L. Li, “Networking, sensing, and controlfor networked control systems: Architectures, algorithms, and applica-tions,” IEEE Trans. Syst. Man Cybern. C, Appl. Rev., vol. 37, no. 2,pp. 157–159, Mar. 2007.

[2] S. Kolla, D. Border, and E. Mayer, “Fieldbus networks for control systemimplementations,” in Proc. Electr. Insul. Conf. Electr. Manuf. Coil WindingExhib., Indianapolis, IN, 2003, pp. 493–498.

[3] F. Xia, Z. Wang, and Y. Sun, “Integrated computation, communicationand control: Towards next revolution in information technology,” in Proc.Int. Conf. Inf. Technol., Hyderabad, India, 2004, pp. 117–125.

[4] K. Ravindran, M. Rabby, and J. Wu, “Protocol-level reconfigurationsfor autonomic management of distributed network services,” in Proc.IFIP/IEEE Int. Symp. Integr. Netw. Manage. Workshops, New York, 2009,pp. 185–192.

[5] M. Niamanesh and R. Jalili, “DRAPS: A framework for dynamic recon-figurable protocol stacks,” J. Inf. Sci. Eng., vol. 25, no. 3, pp. 827–841,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. 379–384.


[7] Y. A. Eracar and M. M. Kokar, “An architecture for software that adaptsto changes in requirements,” J. Syst. Softw., vol. 50, no. 3, pp. 209–219,2000.

[8] H. Chen, C. Zhou, and W. Zhu, “Modelling the protocol stack in NCS withdeterministic and stochastic petri net,” Int. J. Sys. Sci., vol. 42, no. 6,pp. 1057–1064, 2011.

[9] H. Chen, C. Zhou, X. Huang, Q. Yuan, and Y. Shi, “Management ofthe reconfigurable protocol stack based on SDL for networked controlsystems,” Inf. Technol. J., vol. 9, no. 5, pp. 849–863, 2010.

[10] J. Thomesse, “Fieldbus technology in industrial automation,” in Proc.IEEE, Jun. 2005, vol. 93, no. 6, pp. 1073–1101.

[11] J. Decotignie, “Ethernet-based real-time and industrial communications,”Proc. IEEE, vol. 93, no. 6, pp. 1102–1117, Jun. 2005.

[12] V. Vyatkin, H. M. Hanisch, P. Cheng, and Y. Chia-Han, “Closed-loopmodeling in future automation system engineering and validation,” IEEETrans. Syst. Man Cybern. C, Appl. Rev., vol. 39, no. 1, pp. 17–28, Jan.2009.

[13] Di Marco, M. Caporuscio, and P. Inverardi, “Model-based system recon-figuration for dynamic performance management,” J. Syst. Softw., vol. 80,no. 4, pp. 455–473, 2007.

[14] N. Vatanski, J. Georges, C. Aubrun, E. Rondeau, and S. Jamsa-Jounela,“Networked control with delay measurement and estimation,” ControlEng. Pract., vol. 17, no. 2, pp. 231–244, 2009.

[15] F. Lian, J. Moyne, and D. Tilbury, “Network design consideration fordistributed control systems,” IEEE Trans. Control Syst. Technol., vol. 10,no. 2, pp. 297–307, Mar. 2002.

[16] D. Kim, D. Choi, and P. Mohapatra, “Real-time scheduling method fornetworked discrete control systems,” Control Eng. Pract., vol. 17, no. 5,pp. 564–570, 2009.

[17] C. Zhou, C. Xiang, H. Chen, and H. Fang, “Genetic algorithm-baseddynamic reconfiguration for networked control system,” Neural Comput.Appl., vol. 17, no. 2, pp. 153–160, 2008.

[18] A. S. Denazis, S. Karnouskos, T. Suzuki, and S. Yoshizawa, “Component-based execution environments of network elements and a protocol for theirconfiguration,” IEEE Trans. Syst. Man Cybern. C, Appl. Rev., vol. 34,no. 1, pp. 82–96, Feb. 2004.

[19] P. G. Bridges, G. T. Wong, M. Hiltunen, R. D. Schlichting, and M. J. Bar-rick, “A configurable and extensible transport protocol,” IEEE ACMTrans. Netw., vol. 15, no. 6, pp. 1254–1265, Dec. 2007.

[20] International Electrotechnical Commission. (2005) IEC61499: Func-tion Blocks, Parts 1–4, International Standard/Technical Report, 1sted. Geneva, Switzerland. [Online]. Available: http://www.fb61499.com/

[21] K. Thramboulidis, D. Perdikis, and S. Kantas, “Model driven developmentof distributed control applications,” Int. J. Adv. Manuf. Technol., vol. 33,no. 3–4, pp. 233–242, 2007.

[22] T. Strasser, A. Zoitl, F. Auinger, and C. Sunder, “Towards engineeringmethods for reconfiguration of distributed real-time control systems basedon the reference model of IEC61499,” in Holonic and Multi-Agent Systemsfor Manufacturing (ser. Lect. Notes in Comput. Sci.). Berlin, Germany:Springer, 2005, pp. 165–175.

[23] C. Schwab, M. Tangermann, A. Luder, A. Kalogeras, and L. Ferrarini,“Mapping of IEC61499 function blocks to automation protocols within theTORERO approach,” in Proc. Int. Conf. Ind. Informat., Berlin, Germany,2004, pp. 149–154.

[24] M. N. Rooker, C. Sunder, T. Strasser, A. Zoitl, O. Hummer, and G. Eben-hofer, “Zero downtime reconfiguration of distributed automation systems:The CEDAC approach,” in Proc. 3rd Int. Conf. Ind. Appl. Holonic Multi-Agent Syst., 2007, pp. 326–337.

[25] R. W. Brennan, M. Fletcher, and D. H. Norrie, “An agent-based approachto reconfiguration of real-time distributed control systems,” IEEE Trans.Robot. Autom., vol. 18, no. 4, pp. 444–451, 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. 261–265.

[27] M. Wenger, R. Froschauer, A. Zoitl, M. Rooker, G. Ebenhofer, andT. Strasser, “Model-driven engineering of networked industrial automa-tion systems,” in Proc. Int. Conf. Ind. Informat., Osaka, Japan, 2010,pp. 902–907.

[28] R. Froschauer, A. Schimmel, F. Auinger, and A. Zoitl, “Engineering ofcommunication links with AADL in IEC61499 automation and controlsystems,” 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-timeconstrained controlapplications modeled in IEC6 with respect to dynamic

reconfiguration,” in Proc. Int. Conf. Ind. Informat., Perth, WA, Australia,2005, pp. 1499–67.

[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. 1–9.

[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. 1499–16.

[33] P. Pedreiras and L. Almeida, “EDF message scheduling on controller areanetwork,” Comput. Control Eng. J., vol. 13, no. 4, pp. 163–170, 2002.

[34] R. W. Brennan, P. Vrba, P. Tichy, A. Zoitl, C. Sunder, T. Strasser, andV. Marik, “Development in dynamic and intelligent reconfiguration ofindustrial automation,” Comput. Ind., vol. 59, no. 6, pp. 533–547, 2008.

Chunjie Zhou was born in Hubei, China, in 1965. Hereceived the M.S. and Ph.D. degrees in control theoryand control engineering from the Huazhong Univer-sity of Science and Technology, Wuhan, China, in1991 and 2001, respectively.

He is currently a Doctoral Tutor Professor withthe Department of Control Science and Engineering,Huazhong University of Science and Technology. Hisresearch interests include industrial communication,artificial intelligent, and theory and application ofnetworked control system.

Hui Chen was born in Fujian, China, in 1982. He re-ceived the B.Sc. degree in electrical and electronicsengineering from the University of Fuzhou, Fuzhou,China, in 2005, and the M.S. degree in control theoryand control engineering from the Huazhong Univer-sity of Science and Technology, Wuhan, China, in2007, under the supervision of Z. Chunjie, where heis currently working toward the Ph.D. degree in con-trol science and engineering.

His research interests include formal descriptiontechnology and industrial communication.

Naixue Xiong (S’07–M’08) 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.


Xiongfeng Huang was born in Hubei, China, in 1980.He received the B.S. degree in automation from theWuhan University of Hydraulic and Electrical Engi-neering, Yichang, China, in 2002, and the M.S. degreein control theory and control engineering from ChinaThree Gorges University, Yichang, China, in 2009.He is currently working toward the Ph.D. degree incontrol science and engineering with the HuazhongUniversity of Science and Technology, Wuhan China.

His research interests include industrial commu-nication and theory and application of networked

control system.

Athanasios V. Vasilakos (M’95–SM’09) receivedthe B.S. degree in electrical and computer engineer-ing from the University of Thrace, Xanthi, Greece, in1983, the M.S. degree in computer engineering fromthe University of Massachusetts, Amherst, in 1986,and the Ph.D. degree in computer engineering fromthe University of Patras, Patras, Greece, in 1988.

He is currently a Professor with the Departmentof 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 TechnicalUniversity of Athens, Athens, Greece. He has authored or coauthored morethan 200 technical papers in major international journals and conferences. Heis also the author or coauthor of five books and 20 book chapters in the areas ofcommunications.

Prof. Vasilakos was the General Chair, the TPC Chair, and the SymposiumChair for many international conferences. He was or has been the Editor or/andGuest Editor for many technical journals, such as the IEEE TRANSACTIONS

ON SYSTEMS, MAN, AND CYBERNETICS—PART B: CYBERNETICS, the IEEETRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, THE IEEETRANSACTIONS ON WIRELESS COMMUNICATIONS, and ACM Transactions onAutonomous and Adaptive Systems. He is the Founding Editor-in-Chief of theInternational Journal of Adaptive and Autonomous Communications Systemsand International Journal of Arts and Technolog. He is the Chairman of theIntelligent Systems Applications Technical Committee of the IEEE Computa-tional Intelligence Society.

Documents

Model-Driven Development of Reconfigurable Protocol Stack for Networked Control Systems