A Unified Framework for the Design of Distributed
Cyber-Physical Systems – Industrial Automation
Example
Suraksha S. Setty, Humaa Yaqoob, Avinash Malik, Kevin I-Kai Wang, Zoran Salcic, Heejong Park, Udayanto Dwi Atmojo
Department of Electrical and Computer Engineering
The University of Auckland
{ssat034, hyaq414}@aucklanduni.ac.nz, {a.malik, kevin.wang, z.salcic}@auckland.ac.nz
Abstract—Modern manufacturing systems are best examples
where networked embedded controllers and mechatronic devices
form the so-called distributed cyber physical systems (CPS).
Design and deployment of such systems pose significant
challenges to traditional PLC-based software design approaches. In
this paper, a unified framework for the design and deployment of
such systems based on a formal language, SystemJ, is presented.
The proposed framework supports implementing distributed CPS
at system level abstraction with correct by construction design. The
designed software components can easily interact with each other
and with web-based interface for modelling and validation via
simulation and subsequently run on embedded controllers without
any change, which simplifies the design and implementation
process significantly. An ice-cream manufacturing system (ICMF)
example is presented to illustrate the proposed approach.
Keywords—distributed cyber physical systems; on-demand
manufacturing; SystemJ; industrial automation;
I. INTRODUCTION
The web is quickly becoming an integral part of everyday
life as one of the top five forces shaping industry [1]. Both
customers and operators are increasingly demanding to have
access to production systems while maintaining a hands-off
approach to physical units. To keep up with this growing
demand, industrial systems are moving towards the paradigm
of web/cloud-based distributed cyber-physical systems
(CPS). Such systems provide better accessibility and
engagement between customers, operators and physical
manufacturing units and require production processes to be
more flexible, adaptive, and customizable.
Today’s manufacturing industries are under increasing
pressures in meeting strict time-to-market. Manufacturing
systems are typically distributed with communicating
embedded controllers that control physical mechatronic
devices. Designers of such systems face problems when
composing control behaviors of individual controllers and
other software components that make the overall systems as
the systems: (1) are highly concurrent, (2) have continuous
interaction with their environment, (3) must be robust, and
(4) must be modular and (5) allow easy customization.
Implementing such systems by using low-level software
abstraction, such as traditional programming languages or
ladder logics may distract system designers from seeing
broader system functionality and can lead to increasing
development and validation time. Moreover, rapidly
978-1-4799-8389-6/15/$31.00 2015
c IEEE
changing market requires systems to quickly adapt and
customize by reconfiguring the existing system without
interfering too much with intricate details of the low-level
implementation details.
In this paper, we introduce a model-based design
framework to design and implement distributed
manufacturing automation system, including their control
part, as an example of a complex CPS. The framework
unifies modelling of target systems and automatic generation
of control logic from specifications using SystemJ language
[2] and provides seamless execution on distributed platforms.
The language is based on a formal Globally Asynchronous
Locally Synchronous (GALS) Model of Computation (MoC)
[3] that results in correct by construction design and
programming methodology. The system functionality,
including control logic, is described and customized at highly
abstracted system specification level while also being
directly executable at any stage of the design process on the
development platform. The framework enables to build a
simulation test-bench (model) of required details to check for
design accuracy and also to deploy the same design, without
modifications, to the final embedded controllers of a physical
manufacturing system.
By having the aforementioned capabilities, a designer is
able (1) to quickly explore various design options for
distributed manufacturing systems by implementing control
logic at system level abstraction and interacting with web-
based simulation interfaces and (2) to easily describe
behaviors that detect changes in system operation to adapt
control logic in order to deal with product/process
customization/faults. These features are demonstrated on an
example of an industrial system, an automated ice-cream
manufacturing system (ICMF), and represent the major
contributions of the paper. By using the presented
methodology and approach, major advantages of correct by
construction system design and applicability of formal
analysis methods are achievable.
The rest of the paper is organized as follows. Section II
summarizes major existing approaches for designing
distributed CPS. Section III describes and illustrates the
ICMF case study used in this paper, followed by the
proposed design approach presented in section IV. Section V
demonstrates the implemented ICMF, while showcasing
996
system adaptability to meeting customer dem mands. Section
VI concludes the paper and outlines future worrks.
II. RELATED WORKS
Traditionally, the design of industrial autommation systems
are driven by electrical engineers and the control logics
were specified in a circuit/relay-like fashion for the ease of
implementation and understanding. Such appproach causes
difficulty in design verification and reusabilityy. International
standard IEC 61131-3 was revised in 2013 and specifies
four languages for programming PLCs ((Programmable
Logic Controller) namely ladder logics, structure text,
instruction list, and function block diagrram [4]. This
improves the reusability of software compoonents, but the
standard was not designed to target distribbuted systems,
which are today’s norm in manufacturing systems. New
international standard IEC 61499 was introduuced to provide
better support for modelling and designinng distributed
manufacturing systems [5]. However, mosst of the IEC
61499 implementations still lack formal MooC and heavily
rely on the runtime environment [6].
Beyond the industrial automation, distribbuted CPS are
found in many application domains such as sm mart homes [7]
and surveillance [8, 9]. Such systems commoonly use multi-
agent-based design paradigm in the implementation of
distributed CPS. Individual behaviors are aabstracted and
implemented as autonomous agents, which inteeract with each
other to achieve common collective goals. N
Numerous agent
frameworks are developed and some popular oones are JADE
(Java Agent Development Framework) [10], A AF-APL (Agent
Factory Agent Programming Language) [111], and JAL
(JACK Agent Language) [12]. However, aggent execution
typically requires the accompanied Aggent Runtime
Environment (ARE), which limits the portabiility of agents’
deployment. In addition, most existing agennt frameworks
lack of any formal semantics and hence m making design
verification more challenging [13, 14].
In this paper, a unified framework targetinng the design of
distributed CPS with ease of modelling, im mplementation,
portability, validation and adaptability, is proposed and
introduced via an example of a customized and adaptable
manufacturing automation system.
III. CASE STUDY- A CUSTOMIZED ICE-C
CREAM
MANUFACTURING SYSTEM
In this section, an ice-cream manufaccturing system
(ICMF) is used as a motivating example to demonstrate a
typical distributed CPS. Obviously, similar reeasoning would
be applicable to other types of products. The ssystem requires
the ability to handle acquisition of ice-cream oorders from the
buyers, translation of the orders to the manufacturing
process specification and the execution of the necessary
process, including the orchestration of distribbuted software
and hardware components, resulting in the finnal product (set
of ordered ice-creams). The ICMF is a typiccal example of
manufacturing systems since the final prooduct (i.e. ice
cream) can have different compositions from m one order to
the other.
2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA)
(a)
(b)
Fig. 1. (a) A subsection of the automateed ICMF that consists of a single
loader (SL), dual loader (DL), processin
ng station (PS), and storage station
(SS). Photo eyes (PEs) are shown by red dots,
d and the direction of conveyor
movement is indicated. (b) FESTO modullar production system.
A. Physical infrastructure
The physical platform of the ICMF (depicted in Fig. 1)
[15] is a mixed pneumatic/mechaatronic system that consists
of (1) a central conveyor netw work with two embedded
controllers and (2) four additio onal process stations, each
with its own functionality and sepparate embedded controller.
The conveyor network comprisess of four sections of track as
highlighted in Fig. 1. These can be
b individually controlled in
terms of their motion direction and
a stop/start functionality.
The L-shape and Norm tracks are controlled with one
embedded controller, while the Mid
M and End conveyors are
controlled by the other controller..
The single loader (SL) holds one type of work piece (i.e.
one ice cream flavor in this ex xample), whereas the dual
loader (DL) holds two types. Both h loader stations take part in
manufacturing process accordin ng to customers’ demands
when an order is made, by placcing a work piece onto the
conveyor track. These pieces then n proceed to the processing
station (PS) for completion of the ice-cream, in sequence,
where their presence is detected byb the photo-electric sensor
(Photo Eye, PE) which can then signal the conveyor to halt
until the station completes its opeeration. The conveyors then
move the work piece to the storag ge station (SS). Again, a PE
determines the work piece presen nce and allows the station to
pick and place the work piece on nto its storage racks where
placement is monitored and tracked so that they are not
placed on top of an existing tub.
The entire system is prototyp ped using FESTO Modular
Production System (MPS) as show wn in Fig. 1(b) [15]. Instead
of traditional PLCs, all controllerrs are implemented using a
standard BeagleBone Black (B BBB) embedded controller
[16]. Each mechatronic station n, including conveyors as
described earlier, is wired throug
gh a junction box, which is
then connected to a purpose-built I/O cape directly into BBB.
Each BBB is statically configuredd to a unique IP address and
can be accessed through a com mmon IP network. These
physical connections are representted in Fig. 2.
997
 clock domain to be deployed on any JVM running on
distributed platform under assumption
a that physical
interfacing constraints are takeen into account. SystemJ
compilation/design flow is illustraated in Fig. 4. By default, in
first instance, clock domains will run on the development
computer JVM, where the firstt functional model of the
designed system is established. Su ubsequently, clock domains
Fig. 2. Each physical machine is controlled by an ARM-based can be grouped by virtually any criterion and deployed on
BeagleBone Black embedded controller. Multiple BeaglleBone controllers separate computers within a disttributed platform. The only
are inconnected over IP network with local PC or remote server.
Embedded Controllers
additional requirement is to define
d the communication
EC1 EC2 EC3 EC4 EC5 EC6 mechanisms between computerss which will be used for
C1 C2 SL DL PS SS actual implementation of channels declared for
communication between clock k domains on different
computers. This is provided viaa configuration files which
Ethernet specify the host computer for eacch clock domain, including
Router
its IP address and underlying com mmunication protocol (e.g.
Internet TCP, UDP, CAN etc.). Howeveer, the overall system and
Interneet-enabled
individual clock domain functionaality are independent on the
Master Controller
Local PC deevices communication interfaces beetween clock domains.
Configuration files also specify thhe physical implementation
Fig. 3. Network of connected devices of SystemJ interface signals by which
w clock domains interact
In addition to the embedded controllerss that directly with their environment.
interface and control mechatronic devices, tthere is also a SysJ Java
master controller, connected via the IP netw work, aimed to SysJ Program
Compiler
Generated Java
J
Compiler
Class file

oversee the overall system operation and enablle orchestration System

Configuration File SysJ RTS
S
of software components running on multipple embedded
Design/Specification
controllers. IP network allows accessibility tto the Internet Physical
Emulation
and remote devices/interfaces to establish connections for System
Implementation (on Environment)
functions such as remote order placement, IC CMF operation
monitoring and design simulation purposess. The overall
Fig. 4. Design flow of a SystemJ applicaation.
system infrastructure is shown in Fig. 3.
<Interconnection>
IV. SYSTEMJ UNIFIED DESIGN FRAMEW
WORK <Link Type="Destination">
<Interface SubSystem="Ice Cream Controller"
The SystemJ language [2], made for the design of Class="systemj.desktop.TCP
PIPInterface"
Interface="etho0"
reactive, concurrent and distributed systemss, is a logical Args="192.168.1.6:10200"/>
>
choice for the implementation of distributedd CPS. At the ...
same time it is a system-level design languagge with GALS </Link>
</Interconnection>
MoC and as such suitable for formal analysis and reasoning.
The ability to easily combine control-dominnated and data- <SubSystem Name="Main Controller
r" Local="true">
dominated specifications is ideal for industrrial automation <ClockDomain Name="ResourceMa
anagerCD"
Class="ResourceManager">
solutions where both types of modelling are necessary. <iChannel Name="job"
SystemJ provides an ideal mix of featurees for control- From="JobManagerCD.icJobOu
ut" />
<oSignal Name="workStartVa
anilla"IP="192.168.1.8"
dominated and reactive systems augmented by full use of Class="systemj.signals.net
twork.TCPSender"
Java programming language for specificationn of traditional Port="26001"/>
data abstractions, objects and algorithms.
Fig. 5. System configuration file excerpt
e showing interconnection
A SystemJ program consists of mutuallyy asynchronous interface, channel input and signal output declarations.
modules, clock domains, as the top level desiign abstraction. The modular and portable nature of SystemJ based
Within a clock domain, multiple reactionns execute in implementation means that the program/design functional
synchronous parallel, driven by the ticks of a common
model is invariable and independent on the platform it is run
logical clock. These reactions can pass infoormation using
on. As highlighted in Fig. 4, thee same specification can be
broadcasting of signals, whose values are aavailable to all
other reactions within the clock domain with thhe delay of one implemented on either the physical mechatronic devices or
logical tick. The clock domains can commuunicate to each the emulated model of the system m. An example of a system
other using message passing over point-to-ppoint channels configuration file is shown in Fig
g. 5. Interconnection section
synchronized using rendezvous (handshaking) mechanism. specifies available physical communication
c interfaces
linking clock domains running g on different computers.
A SystemJ compiler translates a program m to Java code Individual clock domains are alsoo listed in the configuration
which is then compiled by a Java compiler soo that programs file, along with their communicaation objects, i.e. channels
can execute on virtually any Java Virtual M
Machine (JVM). and signals.
The highly portable nature of the languagee enables each

998 2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA)
 V. DISTRIBUTED CPS IMPLEMENTATTION
The distributed nature of the hardwarre components
requires a similar approach in the softwaree specification.
Each clock domain must be mapped on a sinngle computer.
This section demonstrates how the motivatinng example is
implemented using the proposed SystemJ frramework. The
functionality of the ICMF requires robust and adaptive
handling of customers’ orders, adaptation of beehavior if work
pieces are not available at all loading stationns and runtime
dealing with the faults of conveyor system, jusst to name few.
The control logic must then be able to effecctively manage
customized orders and possible faults withinn the physical
platform and reconfigure the process in ordder to maintain
system operation. The distribution of mechaatronic stations
also introduces the need for reliable networrking. Internet-
based communication links between componnents must be
monitored so that any breakdowns can be quicckly diagnosed
and rectified.
while (true) {
//Wait for go command from sensors.
if(debug) {System.out.println("Awaiting
toStorage");}
await(toStorage);
//Start storing sequence
emit msb("high"); emit mid("high");
emit lsb("high");
pause;
emit vertical("high");
pause;
Fig. 6. The storage station clock domain awaits a signal (toStorage)
from the photo eyes on the conveyor network. Once receiived, it can start its
storing sequence and place the work piece on the rack.
receive customer orders from thee web interface and inform
customers of the job status, and the resource manager which
combines the information of the other
o three clock domains to
allocate jobs onto the physical mechatronic stations. The
individual clock domains pass information between each
other (as denoted by directed arrows)
a so that the entire
system is notified of component proceedings. For example,
the resource manager, after deterrmining device status from
the information received from thet remaining three master
controller clock domains, allocatees a job to one of the loader
stations by passing them the job innformation. Monitoring and
dynamic decision making is also possible, where the master
controller can orchestrate any necessary changes to the
overall system operation. For exammple, if the mid conveyor is
unavailable, system status clock k domain will inform the
resource manager. The resourcee manager can then pass
information to the diverter and L-shaped conveyor (Fig. 1(a))
such that the work pieces are direected around the outer loop
until the mid conveyor can resume. Communications
between clock domains of differen nt stations in the system are
specified using channels within n clock domains, allowing
information to be passed safely prroper handshaking.

A. Mechatronic Station Controller Fig. 7. System architecture of the motivaating case study.
Each mechatronic station has its own softw ware controller } || {
while (true){
implemented as a separate clock domain. T The role of the receive (vanillaUnavailabl
le);
clock domain is to specify computations annd operational Resources.setVActive(false
e);
behaviors in interaction between the contrroller and the }
} || {
mechatronic station using interface (inputt and output) while (true){
signals. For example, processing station opeeration can be receive (storeUnavailable);
triggered by a sensor device (such as a photto-eye) and the Resources.setSActive(false
e);}
}
communication between the processing stationn and sensor is
handled by the corresponding signal. Fig. 6 shoows an excerpt Fig. 8. Parallel reactions in the Reso
ource Manager to monitor device
availability. Channels (vanillaUnavailable, and storeUnavailable) are used
of the SystemJ control code of the storagge station that to determine station status. These chaannels guarentee communication
demonstrates the use of sensor input siggnal in await through handshaking protocols. Error! Reference
R source not found. then
statement to control the storage of a completedd product. shows how this is handled.

The event inputs and control outputs in SystemJ clock By using parallel reactions, the
t master controller clock
domains are all abstracted as signals. Therefore, an domains execute their operatiion while simultaneously
emulation of behavior can be easily develooped such that listening for any changes in the sy
ystem. This allows for quick
functionality can be tested, modified, and verrified on a soft detection of any changes in the phhysical platform and can be
platform before deploying onto physical devices. This used to adapt control behaviors accordingly.
a An example of
emulation can take many forms, from pure console based this parallel operation is shown in
n Error! Reference source
signal interaction to a graphical simulationn of the entire not found., where device availability of each station is
ICMF system. monitored in parallel. The excerrpt shows the single loader
and the storage stations’ availability
a status being
B. Support for Customized Manufacturing Prrocesses concurrently checked. Once the device
d has been deemed to
Fig. 7 shows the overall software system ccomposition of be ‘out’, i.e. disappeared from the network, the resource
the ICMF with each colored box indicating a separate manager can then set the correesponding attributes in the
SystemJ clock domain. The master controlleer (hosted on a master controller. Based on this information, other stations’
local PC) comprises of 4 clock domaains: network usage can be adapted to compen nsate for any losses in the
connectivity to monitor device availability, syystem status to system functionalities. For exam mple, if the single loader
monitor resource (work piece) availability, joob manager to

2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA) 999
 station becomes unavailable, any orders placed are diverted
to the dual loader.
Other aspects of process management such as orders,
and resource outages are managed in a similar manner,
where inputs are handled as and when they arrive without
periodically disrupting the main process. This allows for
runtime adaptability and efficiency, as system functionality
is only modified when required.
C. Adaptive and Fault Tolerant Behaviors
As remote control of distributed physical manufacturing
systems occurs without significant human input,
implementation of automated adaptive and fault-tolerance
mechanisms becomes crucial. This requires the system to
continuously monitor devices for faults and ensure that the
factory process continues its operation without halt. Several
models of fault-tolerance have already been developed in
industries. The method chosen for this project is described
in [17] as the “dynamic configuration of work distribution,
in which faulty units are avoided during work allocation and
work is transferred to redundant units”. In the ICMF, two
types of faults can be diagnosed and handled: 1) device
unavailability and 2) a lack of resources.
With the basic control logic verified and implemented on
the physical platforms, additional fault-tolerance
mechanisms can be added with ease by providing status and
error information from mechatronic stations to the master
controller through dedictaed channels. The states of all
mechatronic stations are processed by the master controller,
or more specifically the system status clock domain. Once
analysed, this information can be passed on to users through
a web interface. The system state information is transferred
to customers making them aware of potential delays to their
orders. Station failures that require actions are displayed to
operators who may inform the master controller, via the web
interface, on the error resolution.
//Manage the state of stations
} || {
//Vanilla Loader
Resources.setVEmpty(false);
while(true) {
//Await empty signal from single loader
receive singleLoaderEmpty;
//Communicate status to the web interface and
//job allocation
Resources.setVEmpty(true);
emit singleIsEmpty(1);
System.err.println("Vanilla loader empty.");
Fig. 9. Single loader station resource monitoring through the use of the
singleLoaderEmpty channel
Faults resulting from a lack of resources (e.g. loading
station is empty) in a station are also addressed. Fig. 9
shows the resource manager receiving information on the
single loader station through the use of the channel
singleLoaderEmpty. The resource manager then diverts
orders to redundant units where applicable. For example,
when the single loader becomes empty, the corresponding
ice cream flavor orders are diverted to the dual loader as
shown in Fig. 10. This requires constant monitoring of
1000 2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA)
stocked quantities to ensure that orders are serviced,
diverted or waitlisted promptly without significant system
downtime. These faults are also handled by dedicated
channels and made visible on the web interface for
customers and operators alike.
//If the order is for vanilla ice-cream
if(ic.isVanilla()) {
//If the vanilla loader is available, allocate
if(Resources.getVActive() && !Resources.getVEmpty()){
emit workStart(ic);
jobStarted = true;
jobHeld = false;
ic.setOrderInProgress();
System.err.println("Job allocated to SL.");
//Otherwise if dual loader available, allocate
} else if
(Resources.getDActive()&&!Resources.getDVEmpty()){
emit workStartVanilla(ic);
jobStarted = true;
jobHeld = false;
ic.setOrderInProgress();
System.err.println("Job allocated to DL.");
}
Fig. 10. Resource Manager diverts vanilla orders to the dual loader if the
single loader is empty or inactive
A fault due to network disconnection is more difficult to
deal with. If a computer loses its connection to the system,
any statuses sent from it will not be received. Therefore, an
external unit that monitors the network connectivity is added
as another clock domain, which constantly checks station
connectivity using polling. By allocating this relatively
intensive functionality in a separate clock domain allows
other operations to continue executing in parallel without
being blocked by unavailable devices. When a station is
deemed to be disconnected, orders are again diverted to
other available units, or for crucial components such as the
conveyor, the system is suspended until a reconnection
signal from the conveyor is received.
During the testing/simulation phase, faults can be
injected into the system through either hardware or software
means of triggering channels and internal signals. Hardware
faults include disconnecting Ethernet links, suspending
movement, or exhausting station supplies. In software, the
same faults can be simulated through manual setting of
channels in order to verify equivalence of reaction to fault.
D. Web Interface
The web interface was developed such that customers
and operators can place orders and/or monitor the state of the
ICMF remotely. This implementation in Java makes use of
the SystemJ constructs where Java code can be seamlessly
integrated (wrapped) into clock domain functionality. This
allows information in the form of an order object to be
passed between Java classes and SystemJ clock domains, as
a signal (i.e. icOrder in Fig. 11). The code excerpts in Fig. 11
show a) the Java class that receives an order placed by the
user through the web page, and sends it to the master
controller and b) the Job Manager clock domain which
receives the order, and can process the information stored in
the IceCreamData object to process the customer requests.
Similarly, information can be passed backward, from
SystemJ controllers to the web interface.
 The web page also provides an interfa face for status The ability of SystemJ clock domains
d to be deployed and
information to be passed to operators who m may not be on run on almost any platform with a JVM gives an interesting
site. A lack of resources or device unavailabiliity information opportunity for future Cloud d technologies. Software
is displayed to attract operator’s attention, andd the option to modules implemented as clock domains
d that do not need to
rectify the fault is provided in the form of a bbutton press, as run on a specific computer can be hosted in a Cloud. In
shown in Fig. 122. This information is then communicated addition, integration of the prop posed SystemJ framework
back to the embedded controllers via signal innterfaces which with the concept of Service Oriented Architecture (SOA)
can then resume, modify, or continue operationn as necessary. can further strengthen the accessiibility and reconfigurability
//JAVA of customized on-demand manufaacturing systems.
//Job send from web to SysJ CD.
SignalSender icOrder = new
SignalSender("127.0.0.1", 20000); REFERENC
CES
... [1] Chatterjee I., Küpper J., Mariager C., Moore P. and Reis S., "The
public void placeOrder(IceCreamData ic) {
decade ahead: Trends that will shap pe the consumer goods industry,"
[handle orders]
//Emit signal to SystemJ Controller. McKinsey & Company, 2010.
icOrder.Send(ic); [2] nd Girault, A., "SystemJ: A GALS
Malik, A., Salcic, Z., Roop, P. S., an
System.out.println("icOrder sent"); } language for system level design," Computer Languages, Systems, &
(a) Structures, vol. 36, pp. 317-344, 20110.
//SYSTEMJ
import comPacket.IceCreamData;
[3] Chapiro, D. M., "Globally-asy ynchronous locally-synchronous
... systems," PhD, Department off Computer Science, Stanford
JobManager( University, California, 1984.
input signal icOrder; [4] IEC 61131-3, Programmable controllers – Part 3: Programmign
output IceCreamData channel icJobOut; languages, International Standard, 2nd edition, 2003.
...
)->{ [5] IEC 61499, Function blocks, International standards, International
{ while(true){//Incoming communication rea action. Electrotechnical Commission, Genev va, Switzerland, 2nd edition, 2012.
IceCreamData localIceCream; [6] Sunder, C. Zoitl, A., Christensen, J. J H., Colla, M., and Strasser, T.,
System.err.println("Waiting for order.");
//Wait for IC order from the web
“Execution models for the IEC 61499 elements composite function
await(icOrder); block and subapplication,” in Procce. of the 5th IEEE International
System.err.println("Got ic order."); Conference on Industrial Informatics (INDIN), 205-214, 2007.
//Fetch data of order when received. [7] Wang, K. I. K., Abdulla, W. H., and d Salcic, Z., "Ambient intelligence
localIceCream = (IceCreamData)#icOrder; platform using multi-agent system and a mobile ubiquitous hardware,"
System.err.println("Received Job: " +
Pervasive and Mobile Computing, vol.v 5, pp. 558-573, 2009.
localIceCream.id);
pause; [8] Lambrou, T. P. and Panayiotou, C. G.,G "Collaborative area monitoring
(b) using wireless sensor networks with stationary and mobile nodes,"
EURASIP Journal on Advances in SignalS Processing, p. 7, 2009.
Fig. 11. a) Excerpt of Java class which sends order informmation to SystemJ
controllers and b) Java object integration into Job Manageer clock domain [9] Malik, A., Salcic, Z., Chong, C., and a Salman Javed, “System-level
approach to the design of a smarrt distributed surveillance system
using systemj,” ACM Trans. Embed d. Comput. Syst. 11, 4, Article 77,
Jan. 2013.
[10] Bellifemine, F., Bergenti, F., Caire, G., and Poggi, A., "JADE—a java
agent development framework," Mu ulti-Agent Programming, pp. 125-
147, 2005.
[11] O'Hare, G. M. P., Collier, R., Drago one, M., O'Grady, M. J., Muldoon,
C., and Montoya, D. J., "Embeedding Agents within Ambient
Intelligent Applications," Bosse, T.(ed.). Agents and Ambient
Intelligence: Achievements and Challenges
C in the Intersection of
Agent Technology and Ambient Inteelligence, 2012.
[12] Bordini, R. H., Braubach, L., Daastani, M., El FSeghrouchni, A.,
Gomez-Sanz, J. J., Leite, J., O Hare, G., Pokahr, A., and Ricci, A., "A
survey of programming languagess and platforms for multi-agent
systems," INFORMATICA-LJUBLJJANA-, vol. 30, p. 33, 2006.
Fig. 12. Web interface showing resource outages to the customer (in red),
[13] Atmojo, U. D., Salcic, Z., Kevin, I., Wang, K., and Park, H., "System-
and the ability for an operator to rectify this (in blue).
level approach to the design of ambient intelligence systems based on
wireless sensor and actuator networks,"
n Journal of Ambient
VI. CONCLUSIONS AND FUTURE W
WORKS Intelligence and Humanized Computing, pp. 1-17, 2014.
Recent developments have indicated thee potential of [14] Atmojo, U. D., Salcic, Z., and Wang, K. I. K., "System-level
approach to the design of collaboraative distributed systems based on
distributed CPS in many application domaains, including wireless sensor and actuator networks,"
n in 5th International
industrial automation. Manufacturing autoomation poses Workshop on Smart Environmentss and Ambient Intelligence, San
serious challenges to traditional software desiign paradigms. Diego, USA, 2013, pp. 634-639.
This paper demonstrates a new design framework to [15] FESTO, “MPS The Modular Produ uction System Stations,” FESTO,
designing distributed CPS based on SystemJ language, and 2014. [Online]. Available: http://www.festo-didactic.com/int-
h
en/learning-systems/mps-the-modular-production-system/stations/.
illustrates it on a real-life example of manufaacturing system [Accessed April 2014].
with adaptive operational behaviors. In adddition, SystemJ [16] BeagleBoard.org, "Beagleboarrd: BeagleBone Black,"
provides simple way of integration with web interfaces. BeagleBoard.org, 2014. [Online]. Available:

2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA) 1001
 http://elinux.org/Beagleboard:BeagleBoneBlack. [Accessed April
2014].
[17] Adlemo A. and Andréasson S.-A., "Models for Fault Tolerance in
Manufacturing Systems," Journal of Intelligent Manufacturing, vol.
3, pp. 1-10, 1992.

1002 2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA)