IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014 27
A Distributed Real-Time Java-Centric Architecturefor Industrial SystemsPablo Basanta-Val and Marisol García-Valls
Abstract—There is a trend in industrial systems towards the useof common-off-the-shelf (COTS) components to develop applica-tions that interact with open systems. This trend includes amongothers the use of high-level languages, such as Java, and Internetprotocols (HTTP and Web Services). Although many industrialsystems use these technologies at their business layers, they are farfrom offering a homogeneous programming platform in their mostinternal infrastructures. This paper extends the current practiceby introducing a real-time Java-centric architecture for industrialsystems. The architecture integrates existing and upcoming tech-nology to define a Java-based approach. The empirical evidence,included in the paper, illustrates the performance of the core of theindustrial layer of this architecture.
Index Terms—Computer architecture, distributed real-timespecification for Java (DRTSJ), middleware, real-time specifica-tion for Java (RTSJ).
I. INTRODUCTION
E MBEDDED systems are suffering a radical transforma-tion in many aspects. Ancient isolated real-time applica-
tions are being interconnected [1]–[4] by wireless (WIFI or thenew 802.15.4 standards) and traditional wired technologies, re-sulting in a new generation of distributed real-time applicationsthat expand to a great variety of domains. The revolution doesnot seem constrained to any particular field [3]–[8]: military,information, surveillance, and even conservative industrial sys-tems may benefit from the technological revolution.However, the new generation of embedded distributed sys-
tems challenges current infrastructures [5] also. In many cases,it must deliver end-to-end real-time performance and offer anacceptable quality-of-service (QoS) in open systems whichmust interact at some point with humans. Other systems havebatteries that must be preserved over the time, introducingnew constraints in the algorithms and models that rule theirbehavior.
Manuscript received December 05, 2011; revised August 06, 2012, October23, 2012; accepted January 24, 2013. Date of publication February 12, 2013;date of current version December 12, 2014. This work was supported in part bythe ARTEMIS Call1 project iLAND under Grant ARTEMIS-JU 100026 fundedby the ARTEMIS JTU and the Spanish Ministry of Industry, Commerce, andTourism, the National REM4VSS under Grant TIN 2011-28339, and by regionale-Madrid (S2009/TIC-1650) projects. Paper no. TII-11-0978.The authors are with the Departarmento de Ingeniería de Telemática,
Universidad Carlos III de Madrid, 28911 Leganés , Madrid, Spain (e-mail:[email protected]; [email protected]).Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org.Digital Object Identifier 10.1109/TII.2013.2246172
One global technology that may speed the adoption of thesenew principles in industrial systems is Java [8]. In an indus-trial environment, Java can be used as a “lingua franca” to fightagainst heterogeneity stemmed from having different kinds ofoperating systems and processing infrastructures. Other advan-tages stem from the availability of additional programming in-terfaces for other domains. So far, Java addressed systems thatrange from the tiny 802.15.4 motes (like SPOT tech [9]) to largeapplication servers (Java EE techs [10]).Java also offers support for real-time and embedded systems,
with commercial products that implement real-time specifi-cation for Java (RTSJ) [11] and promising specifications likedistributed real-time specification for Java (DRTSJ) [12] thattarget distributed environments. Together with other technolo-gies such as JINI (i.e., a fault-tolerant discovery framework)[13] and data-distribution service (DDS) [14], they form thebase of a rather realistic Java-centric approach that eases thedevelopment, deployment, and maintenance of next generationindustrial applications.Unfortunately, real-time Java is a recent technology and its
integration in other Java systems, especially those that expandcurrent real-time Java horizons, requires additional explorationand integration decisions. Some of these technologies, like JINIor DDS, lack a clear characterization of the implications that theuse of a real-time Java virtual machine is going to have on itsinterfaces and the changes they require on its current model toprofit from the predictability of a real-time Java virtual machine.In other cases, like in DRTSJ, the interfaces were defined andimplementations are under development.In this paper, the aim is to contribute a distributed real-time
Java-centric architecture—mainly based on existing technologyand also on upcoming technology—that helps practitioners re-duce the efforts required to support cyber-physical infrastruc-tures for industrial applications. Its main goal is to provide aholistic model that may be particularized or extended to dif-ferent industrial systems, according to application requirements.The architecture may be adapted to requirements coming fromdifferent industrial applications, which may use only a subset oftheir features.To introduce the Java-centric architecture, the remainder of
this paper is organized as follows. Section II introduces the ar-chitecture and how different Java technologies map to particularparts of the architecture. Section III evaluates a subset of thearchitecture. It refers to the performance of the core of the ar-chitecture, which helps to offer empirical evidence on the over-head introduced by core elements of the architecture. Section IVdeals with other architectures proposed for industrial systems.
28 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014
Fig. 1. Overview of the real-time Java-centric architecture for Industrial Sys-tems: layers, networks and technology mappings.
Finally, Section V ends up drawing conclusions and exposingongoing work.
II. DISTRIBUTED JAVA-CENTRIC ARCHITECTURE
A. Requirements
The primary requirements that must be satisfied are givenhere.• Req1: As a general guiding principle, the architecture mustoffer connection to the Internet and to other general pur-pose services and applications.
• Req2: The architecture must offer a flexible industrial op-erational layer. This layer must be able to interconnect iso-lated low-level entities to offer added value applications.Besides, it must provide indirect access to the Internet.
• Req3: The architecture must offer access to industrial net-works and other legacy factory floor elements.
• Req4: The architecture must provide real-time perfor-mance and general quality of service mechanisms.
• Req5: The architecture must deal with the heterogeneityof having different types of infrastructures (e.g., operatingsystems and other execution environments).
B. Global Overview of the Architecture
The proposed architecture defines three operational levels,namely, business, industrial, and device (Fig. 1), described here.• The business level is in charge of providing a generalaccess to the underlying resources via standard accessmethods.
Fig. 2. Temperature alarm detection IA.
• The industry layer is in charge of providing a fully oper-ational layer, which interconnects factory elements to of-fered high-level abstractions. This layer is designed to bemuch simpler and more predictable than the business sub-system. This intermediate platform holds different librariesand services, whichmay be omitted to save resources whennecessary.
• The low-level device layer is in charge of providing fac-tory-level access to different networks. This part of theindustrial application corresponds to those physical nodesthat are closer than others to the physical (industrial) world.Typically, these physical nodes consist of sensors or actu-ators in a factory.
Each level is related to a particular network which intercon-nects the different elements. The high-level network is the busi-ness network (BN), which interconnects general purpose ele-ments (i.e., mail servers, data bases, and file servers) to theInternet. The second network: general purpose real-time net-works (GPRTNs), interconnects special nodes in charge of pro-viding interconnection to different factory floor elements anddifferent industrial services like real-time databases. It is also incharge of controlling the data that are sent from the floor ele-ments to the Internet (devices are not directly connected to thebusiness system; all information should flow via the industriallayer before being sent to the Internet). Lastly, domain machineand sensor networks (DMSN), which are specific to a particularindustrial environment (e.g., Profibus and other wired/wirelessnetworks), provide access to control devices.This physical organization enables the division of program-
ming into three different types of modules: business modules(BMs) which are related to the business applications; indus-trial modules (IMs), which are focused on providing acceptablereal-time performance (necessary to interconnect different de-vice elements); and device modules (DM) which accommodatelow-level access to factory elements. Implicitly, this divisionpromotes modules that may be integrated in high-level deploy-able elements named industrial applications (IAs).
BASANTA-VAL AND GARCÍA-VALLS: DISTRIBUTED REAL-TIME JAVA-CENTRIC ARCHITECTURE FOR INDUSTRIAL SYSTEMS 29
1) Use Case Application: To conclude the overview, Fig. 2shows a use case of a simple application designed for the pro-posed architecture. The goal of the application is to provide asimple alarm system. Basically, in the example, a temperaturealarm flows from a wireless sensor (connected to an 802.15.4network) an industrial node (DCP) that activates a remote fan(connected to Profibus). First, the data flow from the sensor tothe industrial node, which processes the information sent bythe sensor. Next, the DCP node decides to notify the businesslayer about the alarm. Next, the industrial node sends a messagewhich is transferred by the middleware to the business layer andto other subscribed nodes. In this use case, the machine operatoris also notified through the Internet and may connect its laptopto monitor the system.The IA may be modeled as the composition of five modules.
One BM in charge of sending the alarm to the operator; two IMsin charge of triggering the alarm and reacting to the alarm; andanother two DMs that provide access to the sensors and fans.
C. DCP Nodes
In the industrial layer, the Java-centric architecture proposesreusable units called DCP nodes (Distributed Cyber Physical)nodes (called DCP-node in Fig. 1). The advantage offered byencapsulating IAs in DCP nodes is that their code may be easilyreused and accessed at the business level and in other develop-ments. Their particular requirements are given here.• DCP nodes must be able to access factory floor entities andbusiness elements.
• DCP nodes must be able to support a software stack thatallows standard communications.
• DCP nodes must be able to offer end-to-end real-time per-formance in communications.
• DCP nodes must support access to predictable databases.• DCP nodes must offer basic hooks to (predictable) servicediscovery and life cycle management.
• DCP nodesmust offer a general programming space able tohost applications that provide added value (built by usingdifferent device elements and enterprise elements).
D. Java Mappings for the Proposed Industrial Architecture
Here, we show the different technologies chosen to be in-cluded in the core of the proposed architecture. For each layer(i.e., business, industrial, and device), the goal is to propose aset of candidate Java technologies.1) Business Layer: The business layer of an industrial ap-
plication is based on Java EE technology. The use of this tech-nology eases: 1) interoperability with other existing platformsand technologies (through a multiprotocol infrastructure); 2)the definition of reusable industrial-components that model thebusiness logic of the industrial application; and 3) the definitionof high-availability and load-balancing strategies.In the proposed IA, the server includes additional support to
intercommunicate the operator with the factory elements. Toaccomplish this goal, there is an asynchronous real-time tech-nology that monitors and shapes the traffic introduced in theGPRTN. This goal can be satisfied by either extending the sup-port given by Java message service (JMS) [21] or, more directly,using DDS, which already offers the required real-time support
Fig. 3. Relationship between RTSJ and DRTSJ in DCP Java nodes.
Fig. 4. Using RT-Jini to find and invoke a pervasive service.
built in. In both cases, Java EE should not jeopardize the pre-dictability of the industrial subsystem.The server should also offer some kind of quality-of-service
support to the Java EE applications. One choice to provide thissupport is to use the RTSJ. Currently, RTSJ includes supportable to deal with the priority inversion of the garbage collector,and real-time threads to control the amount of processor usedby each component. Demanding this support from the platformopens the door to having real-time performance inside the busi-ness subsystem.2) Industrial Layer: DCP Java nodes (see Fig. 1) may be
equipped with software stacks that may include RTSJ, DRTSJ,RT-Jini, RT-OSGi, and DDS, real-time database support, anddevice driver libraries.RTSJ and DRTSJ: the first technology supports predictable
execution in the local virtual machine. The second extends theoffer to networked applications. Both technologies (RTSJ andDRTSJ) collaborate to accomplish a remote invocation (seeFig. 3). While RTSJ controls the processor in each Java-node,DRTSJ is in charge of controlling the network and coordinatingthe execution in remote nodes, according to a certain end-to-endperformance (typically, a deadline). Both technologies are cru-cial to offer a proper end-to-end real-time performance.RT-Jini: this technology complements RTSJ and DRTSJ
with support for discovering pervasive services. According to[25], this technology: 1) attaches QoS parameters (i.e., cost,guaranteed performance, a priori, and different schedulingparameters) to each service; 2) recovers this information fromthe lookup service later; and 3) optionally, offers some mech-anism to bound complex operations (i.e., find, registration, orcomposition).Fig. 4 shows how a client may use the local engine to search
for a service that is running in another node. Before using thelookup engine, the client needs to be accessible from the engine(step (1) in Fig. 4). After that, the client may use the engine tofind the service (step (2) in the figure) just specifying the nameand the desired performance. Next, the engine returns the list
30 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014
Fig. 5. Relationship between RTSJ, DRTSJ, and OSGi in the DCP node.
Fig. 6. Using DDS as messaging technology among several DCP Java-nodesand the business layer.
Fig. 7. Sensor and DCP-node integration using a RTDB.
of services that fulfill the requirements (step (3) in the figure).After selecting one from the returned list the client many invokethe service via its proxy.RT-OSGi: this service complements RTSJ and DRTSJ with
a framework that manages the life-cycle of an application, a ser-vice registry, and an execution environment. As RTSJ does withschedulable entities, this service introduces a real-time compo-nent characterization which describes each bundle with real-time parameters (like in [26] and [27]). This characterizationis used to execute an application according to certain temporalconstraints. As Fig. 5 shows for a DCP-node, RT-OSGi may runon RTSJ, DRTSJ, and directly on physical resources.DDS: this publisher–subscriber technology enables asyn-
chronous communications between different nodes usingqueues. In the proposed architecture, DDS is used for two dif-ferent purposes. On the one hand, it is used to keep in isolationthe industrial level from the business layer. On the other hand,it may send messages to other DCP-nodes. Fig. 6 shows a nodesending a message (step (1) in the figure) to the subscribedevents; this message is transferred automatically [steps (3) and(4)] to the subscribed nodes by the service [step (2)].Real-time persistence: the last technology that takes part in
the model is the real-time database (RTDB) technology. RTDBsoffer efficient and predictable persistence in those applicationsthat must manage a high amount of data. This database offers(Fig. 7) not only persistence but also management of temporaldata that is typically generated by sensors. The real-time flavor
TABLE ITECHNOLOGIES USED IN EACH LEVEL AND ITS CORRESPONDING FACILITIES IN
THE ENHANCED MODEL (SUMMARY TABLE)
introduces the technology and models necessary to satisfy dead-lines on different operations [28].Device drivers: to access the different protocols and net-
works of the underlying infrastructure, the DCP node introduceslibraries that enable low-level access to various networks andto other industrial systems. Each protocol could be integratedin two ways: 1) using Java native interface (JNI) to connectJava bytecodes to C/C++ libraries offered by the manufacturerand, more directly, 2) using a specific Java API (provided by themanufacturer).A DCP-node may control the downloading and deployment
of libraries using RT-Jini and RT-OSGi. As a general rule, thisaction should be done using RT-Jini in dynamic and pervasiveapplications and using RT-OSGi in environments that are morestatic.3) Device Layer: This layer may contain modules (called
device modules) of an IA if necessary. Although some of themmay be developed directly in Java, many legacy systems tend tobe developed in other low-level programming languages (e.g.,C). One notable exception to this rule is the Oracle SPOT tech-nology, which can be programmed directly on Java.4) Integration Levels for the Different Technologies: Lastly,
Table I contains a summary table which describes the relation-ship among the different technologies used (RTSJ, DDS, OSGi,JINI, DB, and Java EE) and the three levels (
, and ) previously described in this sec-tion. For each level-technology peer, the table shows whetherthe technology is included (Y) or not (-), or whether it is an op-tional element (O). It also describes two integration levels (L0,and L1–L2) for each technology.The basic integration level (L0) does not require complex
changes in existing technologies (basically, it requires beingaccessible from the application). Extra features are requiredat higher integration levels (L1–L2) (explained previously inthe paper and summarized in Table I). The advantage stemmedfrom dividing the architecture into different integration levelsis to allow different industrial applications to choose their cor-responding integration level, according to their requirements.
BASANTA-VAL AND GARCÍA-VALLS: DISTRIBUTED REAL-TIME JAVA-CENTRIC ARCHITECTURE FOR INDUSTRIAL SYSTEMS 31
III. PERFORMANCE EVALUATION WITHINTHE INDUSTRIAL LAYER
Here, we focus on the central part of the architecture: the in-dustrial layer, which is the core of the Java-centric architecture.The experiments are focused on the cost of the remote commu-nications among different real-time nodes by using distributedreal-time Java. Other technologies like Java EE, RT-OSGi, real-time RT-Jini are set aside of the evaluation because they donot have tight real-time constraints such as those existing inend-to-end remote communications. The specifics of the dif-ferent device level technology were also set aside in the eval-uation to focus the evaluation on the DCP Java nodes.The evaluation of the performance offered by DCP nodes is
also relevant for applications that must use different DCP nodesto communicate with an application (such as the application de-scribed in Fig. 2, which has two DCP Java nodes). This perfor-mance establishes operational limitations to the type of applica-tions that may designed with the proposed architecture.In this evaluation scope, the two main goals of the perfor-
mance evaluation section are:1) To provide a metric of the overhead of the communica-tions. The metric is useful to provide a mechanism that al-lows comparing different software implementations undersimilar conditions. To accomplish this goal, the evaluationconsiders the number of remote invocations for the worstcase. The standard cost of the logic in the server is alsotaken into account with low, medium and high overhead.
2) To evaluate the overhead, in terms of % of the blockingtime introduced by the benchmark applications within anapplication. This metric complements the previous onewith overhead information. It is also valid to evaluate andcompare the performance of different DCP Java nodesunder similar application conditions.
The performance is measured by using the specification ofan AUTOSAR application testbed derived from an industrialapplication previously proposed in [29]. It contains test casesthat have operational frequencies that range from 1 to 250 Hz.Two different stacks were evaluated on the industrial
benchmark acting as DCP Java nodes. The first is based onDREQUIEMI [30]–[36]: an academic framework for dis-tributed real-time Java applications based on RMI and anoptimized RTSJ implementation. DREQUIEMI is a goodexponent of a RTSJ-DRTSJ (Level 1) technology support forthe industrial layer. Each node runs on a 768-MHz machineequipped with DREQUIEMI. Currently, DREQUIEMI runsonly on a 2.4.7.-TIMESYS-3.1.214 kernel and RTSJ-RI (theRTSJ-VM of TimeSys). The second type is based on an in-dustrial stack for RTSJ-RMI Oracle JRTS 2.2 [37], running on800 MHz processors, executing a real-time 3.0 Linux kernel.The Oracle JRTS stack is a good example of RTSJ-DRTSJ(Level 0) technology support for the industrial layer. Bothtypes of nodes use the same network infrastructure (100 MbpsSwitched-Ethernet).
A. Throughput Performance
The first experiment considered the use of DREQUIEMIand/or Oracle JRTS as a technology on which to deploy ap-plications. The goal is to find the technological limits of both
TABLE IICOMMUNICATIONS PER SECOND USING DREQUIEMI DCP-JAVA NODES.
786 MHZ–100 MBITS–786 MHZ
TABLE IIICOMMUNICATIONS PER SECOND USING ORACLE JRTS DCP-JAVA NODES.
800 MHZ–100 MBITS–800 MHZ
technologies when they support different application modules.The metric used in the experiment is the number of remoteinvocations carried out; the higher this number is, the betterthe performance delivered. The benchmark quantifies the max-imum number of remote communications that can be carriedout per activation (i.e., in each task period). The maximumnumber of invocations increases as the frequency decreases andwhen the data/work (i.e., low, medium and high) carried outat the server decreases. Taking as reference,low remote invocations require 100 s for their computation atthe server. Medium remote communications take 200 s, andhigh remote communications take 400 s.Results (Tables II and III) show that all nodes may communi-
cate with a remote node within its period at least once. Low-fre-quency/overhead tasks (1 Hz) may carry out hundreds of remotecommunications within a period, while those applications withthe highest frequency (0.25 kHz) can carry out two or three in-vocations only, depending on the type of effort required fromthe server.The two tables are useful for a Java-centric practitioner to
evaluate which of two stacks is the most efficient or providesacceptable behavior (in conformance to design parameters). Inthis particular evaluation, the performance of Oracle JTRS ishigher than the performance offered by DREQUIEMI. Noticethat the Oracle JRTS stack runs on a real-time 3.0 Linux kernel areal-time Java Hotspot virtual machine, whereas DREQUIEMIuses a noncommercial solution (the TimeSys reference imple-mentation). However, depending on the kind of the addressedindustrial application, the practitioner may opt for the less ef-ficient solution (e.g., when both are able to meet the requiredperformance).
32 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014
Fig. 8. Communication overhead due to communications with high, medium and low cost at the server using DREQUIEMI—769 MHz (top) and OracleJRTS-SE-769 (bottom)—100 Mbps.
B. Blocking Due to Communications
Previous section experiments offered an insight of thethroughput offered by DCP Java nodes. This section extendsprevious results considering the interference, in terms ofnormalized blocking time, introduced by the remote communi-cations. In the benchmark three cases were taken into account:1) each task activation requires a single end-to-end communi-cation; 2) each activation requires two communications; and3) each activation requires four communications. The goal ofthe benchmark is to evaluate the amount of time (%) spent incommunication processes including sending time, computationtime at server (low, medium, and high) and receiving time.The lower this time, the better the performance offered by animplementation.The results obtained after the evaluation are shown in
Fig. 8 for the two infrastructures analyzed in this section(DREQUIEMI and Oracle JTRS). The results show some com-binations that are not feasible (e.g., all that require four com-munications are not possible at 0.25 kHz) using DREQUIEMIon 786-MHz machines. As in previous experiments included inthis section, Oracle JRTS outperforms DREQUIEMI playingthe role of an industrial stack (i.e., the performance is higher).From the point of view of the practitioner, the benchmark
allows a Java-centric architect to choose a proper combinationin terms of overhead. If the design rule is that the overhead dueto communications should be at most 10%, the practitioner mayevaluate which of the alternatives is valid from the point of viewof performance.
IV. RELATED WORK
The related work is focused on different pieces of work thatrefer to open current industrial systems and the use of common-off-the-shelf technology in the development of these systems.
For each main approach, the section compares the Java-centricapproach (explained in Section II) against each approach.Bratthall et al. [19] stated the challenges of producing effi-
cient industrial IT architectures. Their approach to deal withthese challenges is the Aspect Object Model (AOM). Our ap-proach offers a predictable Java infrastructure useful to hostAOM applications, complementing the AOM approach withreal-time performance.JSR-7 (Java Specification Request number 7 [15]) was
headed by Cyberonix. Together with other members of theautomation industry, they proposed a real-time cyber tech-nology (RTCT) which relies on the use of a standard protocol:Enterprise Common Protocol (ECP). The approach depicted bythe community process is the construction of a cyber-world forindustrial systems [16]. The DCP-Java node described in theJava-centric approach materializes their ideas on a COTS archi-tecture which may be deployed in heterogeneous frameworks.Cyberonix looked at the concepts of industrial systems from
the Internet perspective. This solution has been applied to pe-troleum retail operations in the eGasStation architecture [16].Our approach complements this cyber-vision with an architec-ture where each element offers predictability via real-time Javasupport.Urdaneta et al. [20] proposed a reference software model in
the petroleum industry context. Their architecture is Java-cen-tric; it is based on a J2EE application server. Our approach issimilar to the solution proposed by Urdaneta: both architecturesshare an enterprise layer and target industrial applications. Nev-ertheless, the architecture proposed enables predictability di-rectly from Java code by means of RTSJ; a key feature not con-sidered by Urdaneta et al.. Therefore, their work may benefitfrom the Java-centric approach model to extend and generalizeits industrial layer.
BASANTA-VAL AND GARCÍA-VALLS: DISTRIBUTED REAL-TIME JAVA-CENTRIC ARCHITECTURE FOR INDUSTRIAL SYSTEMS 33
García-García et al. [22] introduced the Aspect IntegratorPlatform (AIP). Our approach complements the XML-based de-fined in [22], offering a real-time Java-centric platform in whichapplications are deployed. Our architecture may benefit fromthe xml transformations defined in [22] to provide high-levelsystem operations.Service Infrastructure for Real-Time Embedded Networked
Applications (SIRENA) extends the power of service-orientedparadigms (SOAs) to industrial automation [23]. Although thedefinition of an SOA access is beyond the scope of this paper,our Java-centric architecture contains many functional elementsthat may support SOAs. For instance, SOAs may benefit fromthe predictability of a real-time Java virtual machine, and aholistic model on which SOAs may interact with other SOAswithin the industrial system. Likewise, our proposed architec-ture may expose SOAs at its business level (EJBs with SOAaccess).More recently, in the BlueWonder project, Oracle imple-
mented a prototype in an industrial PC (equipped with itsreal-time Java virtual machine, Solaris and Profibus) to controlan industrial system [18]. Its demo, called Sydney, is made upof approximately 200 different elements, which are managedby a single industrial PC. Our architecture extends BlueWonderwith the possibility of having several Java-nodes that carryout coordinated actions by using industrial networks and theInternet.Other architectures, such as that proposed by Thramboulidis
et al. [24], go a step beyond proposing the adoption of tech-niques that belong to the semantic web in the industrial au-tomation context. Essentially, their approach uses a web service-based engine as development platform for industrial automationapplications. Although using semantic web techniques is out ofthe scope of the paper, our architecture may host web-servicesat its business level.These efforts, with the notable exception of BlueWonder,
have used SOA (SOAP, Web Services and ontologies) orenterprise layers (Java EE) in their developments. The use ofreal-time Java (RTSJ) is constrained to specific developments(e.g., in the BlueWonder project) and has not been extended toa networked industrial framework yet. This is exactly the lackthat our holistic Java-centric architecture mitigates shaping areal-time Java centric architecture for industrial systems basedon Java technology.
V. CONCLUSION AND FUTURE WORK
A greater rapprochement between current information tech-nologies (ITs) and current industrial systems (ISs) is still nec-essary to enhance current and future industrial infrastructures.Fortunately, current infrastructures may benefit from solutionspreviously proposed in the Internet. The proposed approach,which advocates an intensive use of Java technologies, helpsby bridging the gap between the old isolated and specific indus-trial networks and the fully open model of the Internet. Fromthe point of view of an industrial system, this intermediate levelmaintains interesting properties; it is able to deliver real-timeperformance, and it is designed to cooperate with the Internet.
This paper has contributed a real-time Java-centric architec-ture for industrial applications which may be particularized de-pending on application needs or extended via standard Javatechnology. The empirical evaluation showed the performanceof the core of this technology via the evaluation of two differentJava stacks. They have illustrated certain performance param-eters that industrial practitioners may expect for their applica-tions when they opt for a real-time Java-centric approach.Our ongoing work focuses on the evaluation of several
802.15.4 motes (SPOTs [9]) from the point of view of theJava-centric architecture described in this paper. In addition,the authors explore service composition and multimedia appli-cation (see [38]–[42]).
ACKNOWLEDGMENT
The authors want to thank the anonymous reviewers forimproving the quality of the manuscript via constructivecontributions.
REFERENCES[1] V. Subramonian, G. Deng, C. Gill, J. Balasubramanian, L. Shen, W.
Otte, D. C. Schmidt, A. Gokhale, and N. Wang, “The design and per-formance of component middleware for QoS-enabled deployment andconfiguration of DRE systems,” J. Syst. Software, vol. 80, no. 5, pp.668–677, May 2007.
[2] I. Lee and O. Sokolsky, “Research challenges in embedded and hybridsystems,” SIGBED Rev., vol. 1, no. 1, pp. 1–5, Apr. 2004.
[3] I. K. Samaras, G. D. Hassapis, and J. V. Gialelis, “A modified DPWSprotocol stack for 6LoWPAN-based wireless sensor networks,” IEEETrans. Ind. Inf., vol. 9, no. 1, pp. 209–217, Feb. 2013.
[4] W. Kang, K. Kapitanova, and S. H. Son, “RDDS: A real-time datadistribution service for cyber-physical systems,” IEEE Trans. Ind. Inf.,vol. 8, no. 2, pp. 393–405, May 2012.
[5] D. C. Schmidt, A. Gokhale, R. E. Schantz, and J. P. Loyall, “Mid-dleware R&D challenges for distributed real-time and embedded sys-tems,” SIGBED Rev., vol. 1, no. 1, pp. 6–12, Apr. 2004.
[6] L. Da Xu, “Enterprise systems: State-of-the-art and Future Trends,”IEEE Trans. Ind. Inf., vol. 7, no. 4, pp. 630–640, Nov. 2011.
[7] G. Cândido, A. W. Colombo, J. Barata, and F. Jammes, “Service-ori-ented infrastructure to support the deployment of evolvable productionsystems,” IEEE Trans. Ind. Inf., vol. 7, no. 4, pp. 759–767, Nov. 2011.
[8] J. Peschke, “Real-time Java for industrial controls in flexible manufac-turing systems,” in Proc. IEEE Ind. Inf. Conf., 2003, pp. 325–331.
[10] JSR-316: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Speci-fication [Online]. Available: http://jcp.org/en/jsr/detail?id=316 Oracle.Available at
[11] J. Gosling and G. Bollella, The Real-Time Specification for Java.Reading, MA, USA: Addison-Wesley Longman, 2000.
[12] J. S. Anderson and E.D. Jensen, “Distributed real-time specification forJava: A status report (digest),” in Proc. 4th Int. Workshop Java Technol.Real-Time Embedded Syst., Paris, France, 2006, pp. 3–9.
[13] J. Waldo, “The Jini architecture for network-centric computing,” ACMCommun., vol. 42, no. 7, pp. 76–82, Jul. 1999.
[14] G. Pardo-Castellote, “OMG data-distribution service: Architecturaloverview,” in Proc. 23rd Int. Conf. Distrib. Computing Syst. Work-shops, 2003, pp. 200–206.
[19] L. G. Bratthall, R. van der Geest, H. Hofmann, E. Jellum, Z. Korendo,R. Martinez, M. Orkisz, C. Zeidler, and J. S. Andersson, “Integratinghundred’s of products through one architecture: the industrial IT archi-tecture,” in Proc. 24th Int. Conf. Software Eng., Orlando, FL, USA,2002, pp. 604–614.
34 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 10, NO. 1, FEBRUARY 2014
[20] G. Urdaneta, J. A. Colmenares, N. V. Queipo, N. Arapé, C. Arévalo,M. Ruz, H. Corzo, and A. Romero, “A reference software architecturefor the development of industrial automation high-level applications inthe petroleum industry,” Comput. Industry, vol. 58, no. 1, pp. 35–45,Jan. 2007.
[21] JavaMessage Service Specification. Oracle. [Online]. Available: http://dlc.sun.com/pdf/816-5904-10/816-5904-10.pdf
[22] R. G. García, E. Gelle, and A. Strohmeier, “A software architecturefor industrial automation,” in Proc. 7th Int. Conf. Enterprise Distrib.Object Computing, 2003, pp. 315–320.
[23] F. Jammes and H. Smit, “Service-oriented paradigms in industrial au-tomation,” IEEE Trans. Ind. Inf., vol. 1, no. 1, pp. 62–70, Feb. 2005.
[24] K. C. Thramboulidis, G. Doukas, and G. Koumoutsos, “A SOA-basedembedded systems devevelopment environment for industrial automa-tion,” EURASIP J. Embedded Syst., vol. 1, pp. 1–1, Jan. 2008.
[25] M. García-Valls, I. Estévez-Ayres, P. Basanta-Val, and C. Delgado-Kloos, “CoSeRT: A framework for composing service-based real-timeapplications,” in Proc. Business Process Manag. Workshops, 2005, pp.329–341.
[26] N. Gui, V. De Flori, H. Sun, and C. Blondia, “A framework for adap-tive real-time applications: The declarative real-time OSGi compo-nent model,” in Proc. 7th Workshop Reflective Adaptive Middleware,Leuven, Belgium, 2008, pp. 35–40.
[27] P. Basanta-Val, M. García-Valls, and I. Estévez-Ayres, “Real-time dis-tribution support for residential gateways based on OSGi,” in Proc.11th IEEE Conf. Consumer Electron., Las Vegas, NV, USA, Jan. 9–12,2011, pp. 747–748.
[28] D. Nystrom, M. Nolin, and C. Norstrom, “Snapshots in real-timedatabases using database pointer transactions,” in Proc. 11th IEEEInt. Conf. Embedded Real-Time Computing Syst. Applic., Hong Kong,2005, pp. 343–349.
[29] W. Guoqiang, M. Da Natale, and A. Sangiovanni-Vincentelli, “Im-proving the size of communication buffers in synchronous models withtime constraints,” IEEE Trans. Ind. Inf., vol. 5, no. 3, pp. 229–240, Aug.2009.
[30] P. Basanta-Val, M. Garcia-Valls, and I. Estevez-Ayres, “No-heap re-mote objects for distributed real-time Java,” ACM Trans. EmbeddedComput. Syst., vol. 10, no. 1, pp. 1–25, Aug. 2010.
[31] P. Basanta-Val, M. Garcia-Valls, and I. Estevez-Ayres, “Simple asyn-chronous remote invocations for distributed real-time Java,” IEEETrans. Ind. Inf., vol. 5, no. 3, pp. 289–298, Aug. 2009.
[32] P. Basanta-Val, M. García-Valls, and I. Estévez-Ayres, “A neutral ar-chitecture for distributed real-time Java based on RMI and RTSJ,” inProc. IEEE Emerging Technol. Factory Autom., Bilbao, Spain, Sep.2010, pp. 13–16.
[33] P. Basanta-Val, I. Estevez-Ayres, M. Garcia-Valls, and L. Almeida, “Asynchronous scheduling service for distributed real-time Java,” IEEETrans. Parallel Distrib. Syst., vol. 21, no. 4, pp. 506–519, Apr. 2010.
[34] P. Basanta-Val, L. Almeida, M. Garcia-Valls, and I. Estevez-Ayres,“Towards a synchronous scheduling service on top of a unicastdistributed real-time Java,” in Proc. 13th IEEE Real Time EmbeddedTechnol. Applic. Symp., 2007, pp. 123–132.
[35] P. Basanta-Val, M. García-Valls, and I. Estévez-Ayres, “Simplifyingthe dualized threading model of RTSJ,” in Proc. 2008 11th IEEE Symp.Object Oriented Real-Time Distrib. Computing, Orlando, FL, USA,2008, pp. 265–272.
[36] P. Basanta-Val, M. Garcia-Valls, and I. Estevez-Ayres, “A dual pro-gramming model for distributed real-time Java,” IEEE Trans. Ind. Inf.,vol. 7, no. 4, pp. 750–758, Nov. 2011.
[37] Java RTS. Oracle, 2011. [Online]. Available: http://www.java.com[38] I. Estevez-Ayres, P. Basanta-Val, M. Garcia-Valls, M. , J. A. Fisteus,
and L. Almeida, “QoS-aware real-time composition algorithms forservice-based applications,” IEEE Trans. Ind. Inf., vol. 5, no. 3, pp.278–288, Aug. 2009.
[39] M. García-Valls, P. Basanta-Val, and I. Estévez-Ayres, “Real-time re-configuration in multimedia embedded systems,” IEEE Trans. Con-sumer Electron., vol. 57, no. 3, pp. 1280–1287, Aug. 2011.
[40] I. Estevez-Ayres, P. Basanta-Val, and M. Garcia-Valls, “Composingand scheduling service-oriented applications in TT-distributedreal-time Java environments,” in Concurrency and Computa-tion. Hoboken, NJ, USA: Wiley, Oct. 2012.
[41] M. Garcia-Valls, I. Rodriguez-Lopez, and L. Fernandez-Villar,“iLAND: An enhanced middleware for real-time reconfiguration ofservice oriented distributed real-time systems,” IEEE Trans. Ind. Inf.,vol. 9, no. 1, pp. 228–236, Feb. 2013.
[42] M. García-Valls, A. Alonso, and J. A. de la Puente, “A dual-band pri-ority assignment algorithm for dynamic QoS resource management,”Future Gener. Comput. Syst., vol. 28, no. 6, pp. 902–912, Jun. 2012.
Pablo Basanta-Val was born in O Valadouro,Lugo, Spain. He received the TelecommunicationEngineering degree from the Universidad de Vigo,Vigo, Spain, in 2001, and the Ph.D. degree from theUniversidad Carlos III de Madrid, Madrid, Spain, in2007.Currently, he is an Assistant Professor with the
Telematics Engineering Department, UniversidadCarlos III de Madrid, Madrid, Spain, and is amember of the Distributed Real-Time Systems Lab-oratory. His research interests are in real-time Java
technology and general-purpose middleware used to support next-generationindustrial applications.
Marisol García-Valls received the Computer Sci-ence Engineering degree from Universitat Jaume Ide Castellón, Castelló de la Plana, Spain, in 1996,and the Ph.D. degree from the Technical Universityof Madrid, Madrid, Spain, in 2001.Currently, she is a Professor with the Telematics
Engineering Department, Universidad Carlos III deMadrid, Madrid, Spain. Since 2002, she has been thehead of the Distributed Real-Time Systems Labora-tory of the GAST Group. Her research interests focuson resource management and quality of service for
distributed embedded real-time systems, real-time middleware, operating sys-tems, and service oriented architectures. She is reviewer of a number of SCI/JCRjournals in these fields; also, she is member of the PC of a number of confer-ences in these areas. She has been enrolled in a number of European, national,and regional projects as the EU projects ARTIST and ARTIST2, and the Euro-pean Network of Excellence ARTISTDesign.
