You are on page 1of 15

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.

You might also like