DEVS-ON A-CHIP: IMPLEMENTING DEVS IN REAL-TIME JAVA ON A TINY INTERNET INTERFACE FOR SCALABLE FACTORY AUTOMATION

Transcription

1 DEVS-ON A-CHIP: IMPLEMENTING DEVS IN REAL-TIME JAVA ON A TINY INTERNET INTERFACE FOR SCALABLE FACTORY AUTOMATION XIAOLIN HU*, B.P. ZEIGLER*, and J. COURETAS** * Dept. of Electrical and Computer Engineering, University of Arizona, Tucson, AZ, USA ** TerraSun L.L.C, Tucson, AZ, USA Abstract This paper describes our effort to implement DEVS on a TINI Chip which has limited memory and processing ability. A set of welldefined DEVS s make it possible to define a just-as-needed DEVS real time environment and run on the chip efficiently. As a case study for real time data gathering, processing and management, a DEVS coupled model has been composed from a set of primitive DEVS atomic models in this application area. This coupled model gets real time temperature from a sensor and runs data processing such as quantizer, moving averager, maximum and minimum extractor, etc. before it transfers the data to database. Keywords DEVS, TINI chip, real time data processing, real time embedded system. 1 Introduction DEVS technology [21] has been usually applied on large-scale dynamic systems, with Java/C++ implementation on various workstations and servers [20,19,6]. As these systems focus on the high level modeling and simulation [12,13], another branch of DEVS application is on real time event-based control and model-based data processing [18,9]. These low-level applications exist largely on scalable factory automation systems, transportation systems and so on. They are usually characterized as intelligent devices with an embedded OS and real time running environment. As the software running on these devices become more and more complicated because of continuous merging between embedded computing and general-purpose computing and increasing interaction between real-time and non real-time systems [16], a formal framework is needed [4] to implement theses real time systems as well as to integrate them with the high level software such as enterprise decision maker [10,3,11]. DEVS, with its formal modeling methodology and scalable infrastructure, provides a possible solution. This paper describes our effort to implement DEVS on a TINI Chip which has limited memory and processing ability. In this paper, we first describe DEVS real time environment and its structure to show DEVS capability in building software for real time systems. Then we introduce the TINI chip and build a temperature processing coupled model to run on it. Finally, from this case study, we conclude that DEVS and its real time environment provide an efficient way to design and implement software for the TINI chip and other similar realtime embedded systems. 2 DEVS Environment 2.1 Defining : Standardize DEVS Implementation As DEVS has been applied on various research and industry areas, many DEVS versions have been developed and implemented. They are implemented on different computer platforms with different program languages. They also vary in modeling level, distribution level and simulation mode such as real-time DEVS and fast-mode DEVS. A set of DEVS interfaces are needed to standardize all these implementation and facilitate future development. There are three types of DEVS interfaces and classes: Supporting s and Classes, DEVS s and Classes, Simulator s and Classes. Supporting s and Classes provide a supporting environment for DEVS implementation. It defines some basic data structures such as Content, Message, Port, etc. These classes are essential for DEVS models and DEVS simulation environment.

2 coupleddevs IODevs Fig. 1: DEVS s DEVS s and Classes provide the modeling environment to build DEVS models. DEVS s define basic functions a DEVS model needs to implement. As we can see from figure 1, it has a hierarchy structure. Among them basicdevs defines the basic functions a DEVS model needs to implement. IODevs interface provides a quick way for a non- DEVS object to communicate with DEVS models. From the figure, we also know that an atomic model implements the Atomic interface, and a coupled model implements the Coupled interface. As the two basic model types in DEVS, both of these two models are subclass of devs and each of them implements its own interface. AtomicsSimulato r RTSimulator Coupled coupled devs CoreSimulator CoupledSimulato r IOBasicDevs Runnable basicdevs CoupledRTSimulato r Atomic atomic Fig. 2: Simulator s atomicdevs entity Entity Coordinator RTCoordinator Simulator s and Classes provides simulation environment in DEVS to run simulation. It defines the functions different simulators need to implement. As we can see from figure 2, the basic interface for DEVS simulator is the CoreSimulator. Under the CoreSimulator, two classes of simulators have been defined. One is for fastmode simulation, such as AtomicSimualtor interface, CoupledSimulator interface and Coordinator interface. Another is for real-time simulation, such as RTSimulator interface, CoupledRTSimulator interface and RTCoordinator interface. RT interfaces add in Runnable Java interface and interpret time as real wall clock time. This means a real time simulator has its own thread and time, so it can control the execution of DEVS models in real time. By carefully defining these DEVS interface and classes, we have a very clear structure for the DEVS environment. This makes it possible to implement a subset of the whole system and define a just-as-needed DEVS environment based on different application scenarios. For example, if we are interested in the real time application such as real-time data management, we only need to implement the part corresponding to real time simulation interface. Similarly, if an application is simple enough to use only atomic model such as some embedded programs which have sole functionality, only the part corresponding to Atomic interface is needed to be implemented. 2.2 Working with Time: Match for Real-time Systems Time is very important in real time systems such as real-time control and real-time data processing. However, conventional OO approach doesn t capture the time property of an object [16,7]. DEVS real time simulator provides a mechanism to introducing time into an object (model). In DEVS real time simulation environment, each atomic model is assigned a real-time simulator to drives the model s running [1]. This simulator will calculate the model s CurrentTime and decide when and how the atomic model to handle the internal and external events in real time. The internal event is an event generated by the model itself whereas the external event is an event received from outside of the model. These two events are handled by the atomic model s internal transition function (? int ) and the external transition function (? ext ), respectively. Below is the pseudo code showing how the simulator driving the model in real time to handle these two events. while (true) t := checkcurrenttime( ); wait for?; y :=?(s); s :=? int(s); tl := checkcurrenttime( ); tn := tl + ta(s); end ( a ) Main simulator thread

3 when receive an external event t := checkcurrenttime( ); e := t - tl; s :=? ext(s,e,x); tl := checkcurrenttime( ); end ( b ) interrupthandler As we can see from the above code, to handle events in real-time, the simulator is conceptually separated in two parts: one is the main thread which handles internal events and acts like a timer in the simulator. The other is interrupthandler which handles external event. Whenever an external event comes in (this may happen at any time in real-time context), the interrupthandler will interrupt the main simulator thread and change the model s state. In this way, the simulator schedules the model s internal event and handle its external event in real-time. Because the simulator is always synchronized to the wall clock time, each atomic model driven by the simulator is a real time object and works closely with time. 2.3 Introducing Activity: Integrate Non-DEVS Algorithm with DEVS As real time control and data processing has been widely used in industry. A lot of function blocks and algorithms have been developed in this area. These algorithms usually are complex and time consuming. They might also include very low-level code to communicate with the hardware. In order to integrate these algorithms into DEVS easily and efficiently, DEVS introduces the Activity concept [18, 14]. An Activity is a thread which wraps the algorithm into DEVS domain. With Activity, a user can design his own algorithm and define it as a DEVS Activity object. The DEVS model will decide when to start/stop an Activity. In this way, any conventional algorithm can be easily integrated into DEVE and driven by DEVS model and simulator. 3 Case Study In factory automation system and transportation systems, low-level real time control, command execution and real time data acquisition, processing and transferring is as important as high-level scheduling and decisionmaking. These low-level applications are usually characterized as intelligent devices (Actuators and sensors) with an embedded OS and real time running environment. As the software running on these devices become more and more complicated, DEVS provides a possible solution to implement these real time systems as well as to integrate them with the high level software such as enterprise decision maker. In this section, as a case study for real time data management, we ll describe how we build DEVS models to get and process real time temperature and run these models on TINI chip. In this example, a DEVS coupled model has been composed from a set of primitive DEVS atomic models. This coupled model gets real time temperature from a sensor periodically (say every 5 seconds) and runs data processing such as quantizer, moving averager, maximum and minimum extrator, etc. before it transfer the data to database. Here we intend to show that all these work has been done using DEVS technology running on the TINI Chip. 3.1 TINI Chip and ibutton Tiny InterNet (TINI) [17] is a platform developed by Dallas Semiconductor to provide system designers and software developers with a simple, flexible and cost effective means to design a wide variety of hardware devices being able to connect to the networks. The platform is a combination of a small but powerful chipset and a Java TM - programmable runtime environment. The chipset provides processing, control, device-level communication and networking capabilities. A set of Java application programming interfaces are provided for the software developer to utilize and control the underlying hardware. The primary objective of this TINI platform is to give everything from small sensors and actuators to factory automation equipment and legacy hardware a voice on the network. This allows the devices to be monitored, controlled and managed remotely. The ibutton [5] is a 16mm computer chip armored in a stainless steel can. The steel button is strong enough so it can withstand harsh outdoor environments. It is also durable enough for a person to carry it everyday so it s always reachable. There are three kinds of ibuttons: Memory ibutton, Java -powered cryptographic ibutton and Thermochron ibutton. Memory ibutton has computer memory so information can be stored and accessed. Java -powered cryptographic ibutton has a microprocessor and a Java Virtual Machine (VM) that is Java Card 2.0-compliant so it is programmable. Its greatest promise lies in its capacity to interact with

4 Internet applications to support strong remote authentication. Thermochron ibutton records temperature and time so people can track the previous temperature. In our case study, a Thermochron ibutton works with TINI Chip and we use it to get real time temperature. 3.2 DEVS Running Environment As we know from the above introduction, the chip has an embedded Java Virtual Machine (JVM). In order to run DEVS model on this chip, we need to define the DEVS model and its running environment and then put them on the chip. Because the chip has limited memory and process ability, everything has to be kept as clean as possible. For this case study, since it is a real time environment, we only need to implement the real time simulation interface. Because we are interested in a set of data processes, a coupled model is needed to do this. The code to run this model will look similar to this: TINI_Module tm = new TINI_Module(); Rtcoordinator rtcd = new RTcoordinator(tm); rtcd.initialize(); rtcd.simulate(); Here TINI_Module is a DEVS coupled model. Rtcoordinator is a real time simulator. By call the simulate() function, we can start the simulation with the coupled model. 3.3 Data Processing Model Figure 3 shows the structure of the data processing coupled model running on TINI Chip. Sensor Data Gathering BlockAve MovingAve QuantumFilter Data Processing PeriodMaxMin OutputProxy Data Transferring File Fig. 3: Data Processing Coupled Model DB In this diagram, each rectangle is a DEVS atomic model. It acts as a function block in the system. The solid arrow shows data flow in the system. In DEVS domain, this is the coupling between atomic models. Note that we intend to keep each atomic model as primitive as possible so they can be reused in the future. Also we intend to implement all the data processing in real-time mode, though some of them could work in non- real-time mode. Below is the brief introduction for each atomic model. Sensor Model: This model is used to collect temperature periodically (say every 5 second). Because this model interacts with the temperature sensor, a DEVS Activity is developed to deal with this hardware interaction. The Sensor model starts this Activity periodically to get the real time temperature. QuantumFilter Model: This model is based on the quantizer theory. It s has been studied that a properly chosen quantizer will reduce data traffic and keep the needed data precision [22, 8]. In this model, the quantizer is set to 0.5. This means the model won t generate output unless the accumulative temperature change is greater than 0.5. It also means the largest data error is 0.5. MovingAve Model: This model is based on the moving average concept in time series theory [15, 2]. It works with a data queue (with size 48) to store moving average value. Every half an hour, it gets the previous value (which is the value of last day at this time) fro m the queue head and calculates the new moving average with the current temperature and then pushes the new value to the queue tail. Here we assume the temperate changes periodically and the period is 24 hours. Using these moving average values in the queue, we can have an approximate prediction for next day s temperatures. BlockAve and PeriodMaxMin Model: These models are used to find last day s Maximum and Minimum temperature and the time associated with them. These Maximum and Minimum values and times are useful to describe daily temperature patterns. Here BlockAve is used to reduce the effect of noise by averaging the data on a short period of time. OutputProxy Model: Whenever it gets an input, this model will simply pass the data to the Database on PC using Java socket. By putting all these atomic models together, we have a small but complete real time data management system (a DEVS coupled model). This system includes data gathering section (Sensor Model), data processing section (QuantumFilter, MovingAve, BlockAve and PeriodMaxMin Model) and data transferring section (OutputProxy Model). With the help of DEVS modeling and real time simulation

5 environment, the system is well-structured, easyto-implement and work closely with time. All these are essential for real time systems and embedded software systems, which exist almost everywhere in our daily lives. design and implement software for the Tini chip and other similar real-time embedded systems. This small real time system also shows good prospect to be scaled up to a real scalable factory automation system. 3.4 Data Result and Future Work Figure 4 shows the real time data the DEVS coupled model collected from the temperature sensor located in our Computer Lab. The solid line shows real time temperature. The dashed line shows the moving average which is calculated from the temperature of previous days. Also, the PeriodMaxMin Model recorded that the maximum temperature is about 81.5 or 79.6 which happens on about 4:00PM. The minimum temperature is approximate 76.5 which happens on about 2:00AM. As we can see from figure 4, these measures match the real time data. As the emphasis of this paper is not on the data and pattern itself, we reserve the exploration of these data for other papers. value Fig. 4: Data Result Out future work will be conducted on three different aspects: First, we will add more sensors into the system and continue our effort to develop DEVS models running on TINI chip. Secondly, we will make the system able to configure itself dynamically so it will adapt to its surrounding environment. Thirdly, a framework will be developed to integrate these low-level models with high-level software such as enterprise decision maker. 4 Conclusions Temperature & Moving Average 21-May 22-May 23-May 24-May 25-May 26-May time temperature moving average In this paper, we show DEVS application in the area of real-time event-based control and model-based data processing. A set of well defined DEVS make it possible to define a just-as-needed DEVS real time environment and run on a TINI Chip efficiently. In this case study, DEVS shows its capability to 5 Acknowledgement This research is partially supported by NSF Next Generation Software, EIA , DMI and Terrasun LLC, Tucson, Arizona. References 1. Cho, Y.K. and B.P. Zeigler, Design Considerations for Distributed Real-Time DEVS. in AIS Tucson, AZ 2. Chopra, Sunil, Supply chain management : strategy, planning, and operation, Upper Saddle River, N.J. : Prentice Hall, c Couretas, J., B.P.Zeigler, I. Subramanian and H. Sarjoughian, Capacity analysis for mixed technology production: evaluating production ramp resource modifications via distributed simulation, International Journal of Production Research, 2001, vol.39, No.2, Edward A. Lee, What s Ahead for Embedded Software, IEEE Computer Sept ibutton Overview, 6. Kim, D., S.J. Buckley, and B.P. Zeigler. Distributed Supply Chain Simulation in a DEVS/CORBA Execution Environment. in WSC Phoenix. 7. Kim, K.H. and C. Subbaraman, Dynamic Configuration Management in Reliable Distributed Real-Time Information Systems. IEEE Trans. On Knowledge And Data Engr, (1): p Lee, J.S. and B.P. Zeigler, Space-based Communication Data Management. Jnl. Par. Dist. Comp., Luh, C.J., Zeigler, B.P., Abstracting eventbased control models for high autonomy systems. IEEE Transactions on Systems, Man and Cybernetics. Vol.23, no.1; Jan.- Feb. 1993; p Neal, R., Modeling & Simulation Roadmap 24 July 2000: Section 4: Enterprise Modeling & Simulation, 2000, Integrated Manufacturing Technology Initiative:

6 11. Nidumolu, R., N. Menon, and B.P. Zeigler, Object-Oriented business process modeling and simulation: a discrete-event system specification (DEVS) framework. Sim. Pract. and Theory, : p Sarjoughian, H.S., D. Hild, and B.P. Zeigler, Engineering Distributed Systems: Simulation-Based Co-Design. IEEE Computer, (3): p Sarjoughian, H., B.P. Zeigler, and S.B. Hall, A Layered Modeling and Simulation Architecture for Agent-based System Development. IEEE Proceedings, (2): p Seong, M. Cho, and T. G. Kim, Real-time DEVS Simulation: Concurrent, Time Selective Execution of Combined RT-DEVS Model and Interactive Environment, Proc. Of SCSC-98, July 19-22, 1998, Reno, NV, pp Shumway, Robert H. Time series analysis and its applications, New York : Springer, c Solving the Embedded Systems Crisis, dedsys.html 17. TINI Page, Zeigler, B.P., Kim-J, Extending the DEVS- Scheme knowledge-based simulation environment for real-time event-based control. IEEE Transactions on Robotics and Automation. Vol.9, no.3; June 1993; p Zeigler, B.P., et al., The DEVS Environment for High-Performance Modeling and Simulation. IEEE Comp. Sci. & Eng., (3): p Zeigler, B.P., S. Hall, and H. Sarjoughian, Exploiting HLA and DEVS to Promote Interoperability and Reuse in Lockheed s Corporate Environment. Simulation J., (4): p Zeigler, B.P., T.G. Kim, and H. Praehofer, Theory of Modeling and Simulation. 2 ed. 2000, New York, NY: Academic Press. 22. Zeigler, B.P., et al., Quantization-based Filtering in Distributed Discrete Event Simulation. Jnl. Par. Dist. Comp., 2001.