State Control Using StateChart Diagram and Observer Pattern

Transcription

1 , pp State Control Using StateChart Diagram and Observer Pattern Sang Beom Ha, Cheol-Jung Yoo *, Jihyun Lee Dept. of Software Engineering, Chonbuk National University 567 Baekje-daero, Deokjin-gu, Jeonju-si, Jeollabuk-do Republic of Korea sangb-ha, cjyoo, Abstract Statechart diagram models the dynamic nature of a system used for defining different states of an object during its lifetime. States change by events, so statechart diagrams are useful to model a system that reacts to certain events. The industrial robot software application that controls movements of an industrial robot, a kind of reactive systems should provide well-designed state control. In addition, the hardware devices of an industrial robot currently on offer are frequently changed, and the changes on hardware devices require changes on the parts of the relevant industrial robot software application that control the movements. The industrial robot software application thus should be modifiable, so that it can be adapted to fulfill various needs of industries. To tackle these problems, this paper proposes a state control technique using statechart diagram and observer pattern applied to developing an industrial robot software application. Through applying the observer pattern according to state control information captured using statechart diagram, maintainability and reusability of an industrial robot software application were improved. Keywords: State Control, Observer Pattern, Statechart Diagram, Industrial robot software application 1. Introduction More and more production workers have been replaced by robots [1]. Industrial robots are similar but differ from each other, because they have used various kinds of production environments from manufacturing plants through harvesting the crops. Maintaining an industrial robot is complex because hardware devices, consisting an industrial robot, should be changed whenever a producing environment changes [2]. Thus, industrial robot should be designed modifiable, so that it can be easily tailored to the various production environments. Moreover, industrial robots should react to certain events, so software that controls an industrial robot should provide well-designed state control. As for state control the observer pattern has been recognized as a proper pattern to deal with state changes of a system. Hardware devices are controlled by software, so whenever hardware devices are changed corresponding software parts also should be. However, industrial robot software application is developed without standards, so there are problems such as lack of reuse, high modification and development costs. To solve the problems, researches on open robot software are ongoing [4]. Not all hardware devices change. Roles of some hardware devices are not changed even a given task of an industrial robot changes. External sensors and motors, which are started or stopped in accordance with external inputs, are clear examples. Their original roles are so clear. Even though a given task has changed, their roles are the same as before, sensing states, or starting, or stopping its movement. * Corresponding Author ISSN: IJSEIA Copyright c 2016 SERSC

2 Industrial robot software application design should reflect these characteristics, state control, modifiability and stable devices. The observer pattern is an event based flow control method, used where an observer should react to the state change of an observable object [6, 7]. The observer pattern is usually used in the situation that software has to react instantly to a state change or an environmental change. The situation of an industrial robot and software that controls the robot s movement is very similar. Thus, the observer pattern is highly utilizable pattern in the industrial robot software application development. Accordingly, this paper proposes a technique for identifying state control information by using statechart diagram, and thereafter this paper uses the state control information for applying the observer pattern in an industrial robot software application development so as to secure its maintainability and reusability. The remainder of this paper is organized as follows: In Section 2 of this paper, we explain the composing elements of the observer pattern structure and statechart diagram with their relevance in the industrial robot software application domain. Section 3 proposes an approach for analyzing state control information required in an industrial robot software application. In Section 4, we describe the prototyping results of our approach in an industrial robot software application. And finally in Section 5 we make concluding remarks and future works. 2. Background Works The observer pattern defines one-to-many dependency between objects and when the state of an object changes, objects that depend on the state changed object are notified about the change, so that they update their state automatically [8]. Figure 1 is a general structure of the observer pattern. Figure 1. Structure of the Observer Pattern The observer pattern has been applied to various software development of various domains. X. Liu et al. [8] and S. B. Ha et al. [9] uses the observer pattern with finite state machine for state control, and F. Karimi et al applies the observer pattern to the SoC testbench environment for keeping consistent configuration among directly connected or coupled components through the configuration when a chip configuration has changed at runtime [10]. These researches confirm that the observer pattern supports easy logic implementation and has advantageous for improving reliability and maintainability. Many researches related to reactive programming point out the limitations of the observer pattern [12, 13, 14], but until now many implementations use the observer pattern to deal with state changes of objects at runtime. 164 Copyright c 2016 SERSC

3 Statechart diagram is composed of states of an object, transitions allowed by states, and events, which are cause of transition. States of an object are determined through the values of variables that the object defines [11]. Statechart diagram describes in detail for states of an object and transitions corresponding to the events. The basic statechart diagram is as like in Figure 2. Figure 2. Statechart Diagram [9] Statechart diagram models the dynamic nature of a system used for defining different states of an object during its lifetime. States are changed by events, so statechart diagrams are useful to model a system that reacts to certain events. As mentioned before, X. Liu et al use the observer pattern and finite state machine for implementing watchdog, which is timer hardware. The finite state machine is used for designing state controls for watchdog, and they are implemented by using the state pattern. As the results, they validated that their approach satisfies the feed dog strategy of watchdog better than other approaches. Statechart diagram makes it possible to analyze state control relevant information in detail that should be performed by observers, observables and events of the observer pattern. Statechart diagram thus can support just like in watchdog to analyze the required state controls necessary to design and implement the observer pattern in the industrial robot software application. 3. Analyzing Required State Control This section describes our technique to extract observers that will be used for extracting the required state controls of an industrial robot software application. Our technique extracts observers using statechart diagram that describes the required state changes of a robot, so its purpose is similar to UML state machine diagram. Observers are extracted through 3 steps. Step 1 defines states and events, which are inputs for defining statechart diagram. Step 2 defines statechart diagram using states and events of Step 1. Finally, Step 3 extracts observers based on the defined statechart diagram Step 1: Define States and Events Hardware devices of an industrial robot include Motor, Manipulator, Power supply, End effector, Controller and so on as shown in Figure 3. Copyright c 2016 SERSC 165

4 Figure 3. Basic Hardware Devices of an Industrial Robot [9] An industrial robot changes its states in a specific order for performing a given task, and software controls the movement of each hardware device in accordance with the required state changes. In addition, software should control hardware devices together with monitoring their internal states for processing exceptions, such as a situation that requires a state change to Stop from Moving due to an unexpected situation during a motor operates for moving end effector toward a given coordinate. For extracting observers and observables between an industrial robot and corresponding software that controls the movement of hardware devices, first of all we should analyze possible states and events of hardware devices. Possible states of a hardware device that participates for performing a given task are analyzed. We should carefully define whether a state requires monitoring or event triggering. States for hardware devices are defined according to the template of Table 1. Table 1. Template for State Definition Component Name/API State Required State Control Description.... Default.. Monitoring required Event trigger required Required event Conditions for occurrence The states are defined for all possible states of hardware devices. Physical movements of hardware devices of an industrial robot are correspond to state changes. As shown in Table 1, a state is described with state control information such as whether it is a default state of a hardware device (default) or whether it requires monitoring for occurring an unexpected situation(monitoring required) or whether it requires an event trigger (event trigger required). Description column is filled with detailed explanation of a state, but in the case of a state related to event trigger this column is filled with conditions for event occurrence. In the case of monitoring required state, this column is filled with an exception together with state changes due to the exception. After that, events that bring out state changes of hardware devices based on states in Table 1 are defined. Events are classified as monitoring required states and event trigger required states. The specification of events follows a template of Table Copyright c 2016 SERSC

5 Event Table 2. Template for Event Definition Condition for Event Trigger Original State Changed State Definition of Statechart Diagram In this step we define statechart diagram based on the state and event definition results of Step 1. Statechart diagram is drawn up in accordance with the following sub-steps: Mapping monitoring required and event trigger required states to states of statechart diagram; Adding an event and event trigger condition to transition arrow; and Removing and integrating redundant states and events. Statechart diagram is defined by each hardware device and follows the following notation. Figure 4. Notation Used for Describing States and Events 3.3. Representing Required State Control Using Statechart Diagram At Step 3, we drive observers that will perform actions in accordance with events that require state control. Statechart diagram is used for extracting relevant events. An event is mapped to data what a Subject will monitor, while a hardware device and the API are mapped to an observer. APIs are provided by hardware devices that will be called for controlling the movement of a robot. The structure of the observer pattern used in this paper has Subject and Observer as like the existing observer pattern. Subject registers Observers, and they have a list of Observer objects. However, the Subject of the observer pattern used for an industrial robot software application notifies to the specific Observer, unlike Subject of the existing observer pattern notify a state change to anonymous Observers. Thus the API that will be called is dependent on the type of event. Copyright c 2016 SERSC 167

6 Figure 5. Modified Class Diagram for the Observer Pattern As shown in Figure 5, in our modified observer pattern, ConcreteObserver that implements the Observer interface is a call method for APIs related to hardware devices such as Motor, Manipulator, and End effector. Each observer knows APIs that will be called in accordance with events. The Update method of ConcreteObserver is a method having enumeration, so each parameter is mapped to the specific API that will be called. NotifyObservered method of Subject class is used to control the registered Observers. Each event defined in statechart diagram is mapped to invokenum, which is an argument of NotifyObservered method. 4. Verifying the Effectiveness of State Control This section describes a case applying our state control information derivation method to developing an industrial robot software application. We validate our method by implementing a task that operates a Motor among the industrial robot hardware devices using state control information and the observer pattern. Firstly, we analyzed states and events, which are major inputs of statechart diagram. As the results, the Motor device has three states, Blocked, Moving, and Returning. Returning state is a state that goes back to the location before moving. The default state is Blocked, changed to Moving when an external input or a sensing value from an external sensor satisfies the defined condition and always back from Moving after the specified amount of moving. Table 3 describes the analysis results. Table 3. State Definition for Motor Component Component Name State Required State Control Description Motor Blocked Default Motor/Move Motor/Initialization Moving Returning Event trigger required Monitoring required Event trigger required Monitoring required Movement requested Motor error Initialization requested Error initialization request There are such events, movement, movement completion, initialization, initialization completion, error, error completion. According to the movement event, a state changes from Blocked to Moving while movement completion event is triggered to go back from Moving to Blocked. The initialization event, triggered by an external sensor or input, causes a state change from Blocked to Returning. The initialization event can 168 Copyright c 2016 SERSC

7 only be triggered when the previous state is Moving. There is an event named error, triggered at particular situation during moving. Table 4 shows the defined events. Table 4. Event Definition for Motor Component Event Condition for Event Trigger Old state New state Movement Request from external inputs or sensors Blocked Moving Movement completion Requested amount of movement Moving Blocked Initialization State changed from Moving to Blocked Blocked Returning Initialization completion Returned to the previous position Returning Blocked Error Error occurrence during Moving Moving Returning Error completion State changed from Moving to Returning to deal with Error Returning Blocked Figure 6 shows an example statechart diagram defined in accordance with the analysis results of events, conditions for event trigger, old states, and new states. Figure 6. Statechart Diagram for Motor Component Each state of the Motor statechart diagram is mapped to a parameter of a method that will be invoked when the Subject class updates observers whenever state changes, while each event is implemented through a method of the Observer class that will be used to invoke APIs of hardware devices. However, not all states and events need to be implemented as methods of the Subject class or the Observer class. Those decisions depend on the relevant APIs of hardware devices. For example, both Movement and Movement completion events require state changes from Blocked to Moving and vice versa. They are a pair of events that use the same API, so they are implemented by Movement method. Initialization / Initialization completion and Error / Error completion are the same. They are implemented by Initialization and Error method respectively. The Observer interface and its concrete observer class, Motor class can be designed as following Figure 7. Copyright c 2016 SERSC 169

8 Figure 7. Class Diagram for Motor Component Following is C# sources, implementing the Motor class. IndustrialRobotComponent.class public class IndustrialRobotComponent : Subject private Thread mthreadmotorerror; public IndustrialRobotComponent() addobserver(new MotorComponent(this)); //add Motor observer mthreadmotorerror = new Thread(ThreadMotorError); mthreadmotorerror.start(); public void ThreadMotorError() //case of errors NotifyObserver(Error); public void Movement() NotifyObserver(Moving); public void Initialization() NotifyObserver(Returning); Main class invokes the relevant methods defined in IndustrialRobotComponent class, and the control class notifies a command to the relevant hardware device. In the case of the Error event it requires real time observation, so we implement it through thread. 170 Copyright c 2016 SERSC

9 MotorComponent.class public class MotorComponent : Observer private ExternalLibraries.ExternalMotorIO mexternalmotorio; public MotorObserver() mexternalmotorio = new ExternalLibraries.ExternalMotorIO(); public override void Update(invokeNum minvokenum) switch (minvokenum) case invokenum.movement: //invoke methods related to the Moving state break; case invokenum.initialization: // invoke methods related to the Returning state break; case invokenum.error: // invoke methods related to the Error state break; public enum invokenum Moving = 0, Returning = 1, Error = 2 public void Movement() // invoke Movement-relevant Motor API public void Initialization() // invoke Initialization-relevant Motor API public void Error() // invoke Error-relevant Motor API MotorComponent class invokes the relevant Motor APIs by checking a parameter returned IndustiralRobotComponent class. For example, if Moving state Movement() method is called for invoking Movement-relevant Motor API while if Returning state Initialization() method is called for invoking Initialization-relevant Motor API. Copyright c 2016 SERSC 171

10 5. Conclusions and Future Works This paper used the observer pattern in order to improve the maintainability and reusability of industrial robot software application development. Most of all, because an industrial robot system is a kind of a react system, state control is important to control correct movements through the control software. For applying the observer pattern to developing industrial robot software application, we used statechart diagram for analyzing exact and correct state control. As the results, we could extract observers, observables and events of the observer pattern that improves the maintainability and reusability of an industrial robot software application, which should change whenever hardware devices or a given task change. However, the proposed technique analyzes states, events and transitions for each hardware device and systems, so it is difficult to deal with interactions between hardware devices. Moreover, statechart diagram deals with changes for a single object and some possible states can be missed, so there might be unexpected states and transitions. Therefore, it is difficult to ensure that the proposed approach covers all possible states of the whole system. This can conclude incorrect extraction or missing of observers, observables and events. This limitation is due to the characteristics of statechart diagram. As a future work, we will improve our approach by using the interaction diagram together with statechart diagram. In addition, we will analyze and validate other design patterns that are proper to industrial robot software application. Acknowledgments This work was supported by Business for Software Convergence Cooperative R&D Support funded Jeonju IT&CT Industry Promotion Agency in References [1] G. Ma and G.-Y. Shen, The Present Situation and Developing Trend of Industrial Robot, Modular Machine Tool & Automatic Manufacturing Technique, vol. 3, (2002), pp [2] J. Fang, J. Zhao, F. He and X. Lin, Design and Research of Three-Layers Open Architecture Model for Industrial robot software application System, Proceedings of IEEE International Conference on Mechatronics and Automation (ICMA), (2013), pp [3] U. Hagn, M. Nickl, S. Jorg, G. Passing, T. Bahls, A. Nothhelfer, F Hacker, L. Le-tien, A. Albu-Schaffer, R. Konietschoke and G. Hirzinger, The DLR MIRO: A Versatile Lightweight Robot for Surgical Applications, International Journal of Industrial Robot, vol. 35, no.4, (2008), pp [4] H. Bruyninckx, Open Robot Control Software: The OROCOS Project, Proceedings of the 2001 IEEE International Conference on Robotics & Automation, (2001), pp [5] B. Song, C. Jang, Y. Jeong, S. Kim and H. Choi, Survey on Interoperability Technology in Robot Software Platform, Korean Robotics Society vol. 10, no. 1, (2013), pp [6] E. Gamma, R. Helm, R. Johonson and J. Vlissides, Design Patterns, Addison-Wesley Publishing Company, Inc, Reading, Massachusetts, (1994). [7] G. Naumovich, Using the Observer Design Pattern for Implementation of Data Flow Analyses, Proceedings of the 2002 ACM SIGPLAN-SIGSOFT Workshop on Program Analysis For Software Tools and Engineering, (2002), pp [8] X. Liu, S. Chen and W. Song, A Design and Implementation of Watchdog based on Observer Pttern and Finite State Machine, Proceedings of the IEEE International Conference on Reliability, Maintainability and Safety (ICRMS), (2014), pp [9] S. B. Ha, C. J. Yoo and J. Lee, Observer Extraction Using Statechart Diagram, Asia-pacific Proceedings of Applied Science and Engineering for Better Human Life, vol. 10, (2016), pp [10] F. Karimi, Applications of Decorator and Observer Design Patterns in Functional Verification, Proceedings of the IEEE International Workshop on High Level Design Validation and Test, (2008), pp [11] R. K. Swain, V. Panthi, P. K. Behera and D. P. Mohapatra, Automatic Test Case Generation from UML State Chart Diagram, International Journal of Computer Applications, vol. 42, no. 7, (2012), pp [12] I. Maier and M. Odersky, Deprecating the Observer Pattern with Scala.React, EPFL-REPORT , (2012). 172 Copyright c 2016 SERSC

11 [13] G. Salvaneschi, G. Hintz and M. Mezini, REScala: Bridging Between Object-oriented and Functional Style in Reactive Applications, Proceedings of the 13th international conference on Modularity, (2014), pp [14] G. Salvaneschi and M. Mezini, Reactive Behavior in Object-oriented Applications: An Analysis and a Research Roadmap, Proceedings of the 12th Annual International Conference on Aspect-Oriented Software Development, (2013), pp [15] J. Y. Park, H. M. Noh, C. J. Yoo and J. Lee, Use of the Command Pattern in Industrial robot software application, Asia-pacific Proceedings of Applied Science and Engineering for Better Human Life vol. 10, (2016), pp Authors Sangbeom Ha, He received his BS degree in Software Engineering from Chonbuk National University, Republic of Korea in He is a MS student of Software Engineering, Chonbuk National University. His current research interests include embedded software framework, software visualization and IoT. Cheol-Jung Yoo, He received B.S. degree in Computer Science and Statistics from Chonbuk National University, Jeonju, Korea in 1982, then, M.S. degree in Computer Science and Statistics from Chonnam National University, Kwangju, Korea in 1985, and then, Ph. D. degree in Computer Science and Statistics from Chonbuk National University, Jeonju, Korea in He was a visiting professor in EECS at the University of California Irvine from January 2012 to July He is currently a professor in the Department of Software Engineering, Chonbuk National University, Jeonju, Korea. He is also the Associate Chair of Korea Information Processing Society. His current research interests include interoperability testing of embedded system and software, multimedia system and software, software quality and testing, etc. Jihyun Lee, She received her MS and Ph.D degrees in Computer Sciences from Chonbuk National University in 2000 and 2005, respectively. She was an Assistant Research Professor of KAIST from June 2005 till February She also worked at Daejeon University as an Assistant Professor till February From March 2016, she joined the Department of Software Engineering at Chonbuk National University as an Assistant Professor. Her research interests include software product line, software and product line testing and business process maturity. Copyright c 2016 SERSC 173

12 174 Copyright c 2016 SERSC