Object-Oriented Design Pattern Approach for Modeling and Simulating

Proceedings of the 2001 IEEE International Conference on Robotics & Automation Seoul, Korea • May 21-26, 2001

Object-Oriented Design Pattern Approach for Modeling and Simulating Open Distributed Control System Toyoaki Tomura Asahikawa National College of Technology, Japan e-mail : [email protected]

Hokkaido Univ.

Kiyoshi Uehiro Motorola Japan Ltd., Japan e-mail : [email protected]

Susumu Yamamoto Motorola Japan Ltd., Japan

Abstract

C om pu ter for M onitoring

E th e rn et

An open distributed control system (DCS), which consists of a large number of devices and a single open network interconnecting those devices, is now used in many automation areas. One critical problem of the DCS, however, is that because there is massive traffic on the network, the system integrator must carefully tune the network traffic after the construction of the system to assure its control performance. Hence a DCS simulator is strongly needed. In our study, we propose an object-oriented design pattern approach as a uniform, rapid and accurate method of modeling and simulating a DCS. Two special design patterns are proposed: Statechart Pattern which defines classes and the state-transition execution mechanism for realizing the dynamic behavior of devices, and DeviceConstructor Pattern which defines classes and their instantiation mechanism for realizing the structure of devices composed of many kinds of sensors and actuators. The systematic procedures from those patterns to the executable Java code of the simulation model are also discussed. Furthermore, the effectiveness of our approach was investigated through actually developing an in-house Java-based DCS simulator.

M a s s ive ly D is trib u te d S y s te m C o n tro l N e tw o rk (LonW orks, D evice N et, etc.)

R outer

C o ntro l N o de s

D e vic e

S e n s o rs a n d A c tu a to rs

C o ntro ll e d S ys te m

Figure 1 Typical Structure of Open DCS construction of the system. However, this task, requiring extra time and cost, becomes a bottleneck for rapid development of the DCS. Therefore, the system integrator strongly needs simulation techniques which enable the integrator to make uniform models of the structure and dynamic behavior of each device, to quickly implement the models as executable codes, and accurately estimate the dynamic behavior of the network traffic among the devices through combining those models. In order to satisfy those requirements, object-oriented methodology has been used in modeling several distributed systems. SEMATECH has proposed CIM Application Framework [2] for semiconductor production. It specifies the reference model of the structure of manufacturing resource classes and association among them, and of the dynamic behavior of objects. OSE has proposed OSEC (Open System Environment for Controllers) [3] for open NC controller. It specifies the reference model of structure of function block classes of NC controller and association among them. SEMI’s Common Device Model [4] specifies a reference model of static structure and dynamic behavior of each device composed of various sensors, actuators and local controllers in UML [5]. Those approaches provide the system integrators with objectoriented reference models that can be used in several technical domains, and are very useful for uniform analysis and description of specification of each model to be used for DCS simulation. However, the approaches still have some problems which prevent us from efficiently building executable models necessary for DCS simulation in our study. The problems are as follows:

1. Introduction In recent years, the DCS based on open networks has been rapidly replacing traditional centralized control systems in factory, process and building automation. As shown in Figure 1, the DCS generally consists of a large number of devices composed of sensors, actuators and local controllers, and of a high-speed open network interconnecting those devices. Now we have ControlNet, Foundation Fieldbus, LonWorks, Device-Net, and etc. [1] as examples of such a high-speed open network. The DCS is capable of making the control system more scalable, and its construction and wiring cost much less. For these reasons, the DCS is expected to be used more widely in automation areas in the future. One critical problem of the DCS is that the number of devices tends to be large and massive communication traffics among those devices concentrates on one single network. This causes unacceptable time-delay or fatal loss of data which assure reliable control performance. To avoid this problem, the system integrator must optimize the network traffic by carefully tuning the several communicative timing parameters of each device after the 0-7803-6475-9/01/$10.00© 2001 IEEE

Satoshi KANAI School of Engg.

211

S ta te c h a rt Pa tte rn

U M L & Java S pec ific ations of D evic e’s C om pon en ts K in ds an d N um bers of C om pon en ts

C o ns tru c t C o m p o ne n ts o f D e vi c e

D e vic e C o ns tru c to r Pa tte rn

D evice’s C om ponen t M odels

C o ns tru c ti o n M e th o d ol o g y o f D e vi c e M o d e l

T ra n s itio n

entry / action -exp ression do/ a ction-ex pression ex it/ a ction-ex pression

D evic e M odel

In itia l p s e u d o s ta te F in a l s ta te

D CS S im ula tio n

S im ulation R esult

C o n c u rre n t s u b s ta te s S t ate-n am e

M o d e l in g T o ol

C ontrol P aram eters and Binding Infor m ation

ev e nt-sig nature [gua rd-con dition] / ac tion-ex pre ssion

S t ate-n am e U M L & Java

C o ns tru c t S ta ti c S tru c tur e o f D e vi c e M o d e l

Im p l e m e n ta ti o n M e tho d o lo g y o f S ta te c h a rt D i a g ra m

S ta te

E1

Figure 2 Overview of Modeling and Simulation of DCS

E2 S2

S1

D C S S i m u l a to r

E3 S3

1) The reference models can only define the minimum required structure of classes and association among them, or state-transitions, and they do not have a detailed mechanism for implementing them. In additon, they fail to specify mechanisms for creating objects dynamically, for uniform management of the objects of various concrete subclasses inherited from abstract reference models, and for interacting the objects to actually execute the state-transition. 2) The concrete implementing procedure to bridge between the reference models and the executable codes of the simulation model is not explicitly given.

S e q u e n tia l s u b s ta te s S tate-n am e

E4 S4

E1 S1

E2 S2

Figure 3 Notation of Statechart Diagram simulation of the DCS based on the proposed two patterns. In each process, the system integrator’s tasks are as follows: 1) To construct the static structures and dynamic behaviors of the devices components by referring to the specifications of the components. The Device Constructor and Statechart patterns are used. 2) To construct the static structure of a device model by using the Device-Constructor pattern. 3) To connect the device model with the open DCS simulation model (which can simulate its communication protocol), and then evaluate network properties such as traffic on the network and packet collision frequencies.

Recently, “Design Pattern” approaches [6] and [7] are used in the object-oriented design process. The design pattern approach specifies reusable mechanisms for collaboration and communication among classes or among objects to solve common object-oriented problems in a general domain. Generally, the approach classifies design patterns into three categories: patterns for creating objects, patterns for defining the structure of objects, and patterns for defining the behavior of the objects. Although the design pattern approach can solve the first problem mentioned above by combining several basic patterns, it still fails to solve the second one. In order to solve the two problems at the same time, we propose a new objectoriented design approach for modeling and simulating a DCS. The purposes of our study are:

In order to execute those processes, Motorola Japan, Inc. has developed a modeling tool for the device model and the DCS simulator using the proposed design patterns. This simulator is actually used in designing and evaluating the actual DCS governed by LonWorks for a heating-cooling system in the building automation area. 3. Statechart Pattern In order to model a device, the system designer must develop all the device-specific component models with dynamic behavior. A statechart diagram [5] can describe the detailed dynamic behavior of a device-specific component model. In order to implement the statechart diagram systematically and easily, the system designer needs a design pattern and an imple-mentation methodology based on it. In this section, we describe the Statechart pattern and the implementation methodology with the pattern, which are proposed in our study.

1) We propose two design patterns for modeling a DCS, that is, Statechart which defines classes and state-transition execution mechanism for realizing the dynamic behavior of devices, and DeviceCo n structor which defines c lasse s and t heir instantiation mechanism for realizing the static structure of devices. 2) We also discuss a systematic implementation procedure to bridge from those patterns to the executable Java code of the simulation model. 3) We confirm the effectiveness of our proposed approach based on those patterns through actually developing an in-house Java-based DCS simulator for building automation.

3.1 Statechart Diagram The statechart diagram describes the dynamic behavior in common with all the objects of a class. In particular, it describes possible sequences of states and actions through which an object can proceed during its life as a result of reacting to discrete events. The notation of the statechart diagram are substantially those of Harel’s statechart [8] with extensions to make them object-oriented. Figure 3 shows the notation of the statechart diagram.

2. Modeling and Simulation of DCS Figure 2 shows a process overview of modeling and

212

Table 1 Patterns for Implementing Statechart Diagram

< > E n tryA c tio nS tra te gy

- entry

P atterns

1

< > G u a rd S tr a te g y

+ exec uteE n try(s tate : S tr ing)

C as e S tatem e nt in a S w itch Sta tem ent

O bjec t of Subclass of C lass S ta te

S tate O bject

S tate or S tate M achin e O bjcet

C han ging Value of S tate V ar iable

C re ating and D eleting S tate O bject

T ransition O bject

T ransition O bject

E vent V ariable

E vent V ariable of C lass S tate

E vent V ariable

S tring (A rgum ent of M eth od)

M eth od of C lass C o nte xt

O verr ided M eth od of C lass S ta te

M eth od of C lass C onte xt

Interf ace

S tate V ar iable

Attrib ute of C lass S tate M achin e

S ta te V ariable

Attrib ute of C lass S ta te

< > D o A c ti vi tyS trate g y

- do 1

1

< > A c ti o n Str a te g y

+ exe cuteD o(s tate : S tring ) < > E x i tA cti o nS tr a teg y

- exit

- gua rd

+ evalu ateG ua rd( 1 sign : S trin g, para : O bject) : boolean

Elem ents

- action

+ execute A ction(s ign : 1 S tring, para : O bject)

+ executeExit(state : String ) < > G u a rd s

< > E n tryA c ti on s < > D o Ac ti viti e s

C o nte x t

< > A c tio ns

+ eventO ccured(s ign : S tring, para : O bject) : S tate

U se r-d e fin e d

1 1

1

- stateM ac h ine

S ta te M a c hi ne G ood

< > E x i tA c ti o n s

G o od

N ot B ad

1

S ta te

1

1..*

# nam e : S tring 1 N ot B ad

1

- cu rrent S tate

1

G o od

N ot B ad

1

3.2 Previous Design Patterns Table 1 shows design patterns for implementing the dynamic behavior described by statechart diagram [6], [7], [9]. These patterns except the Statechart pattern have critical problems in easiness of implementation, support of substates, and corresponsibility to the Java code. In order to solve these problems. the system designer needs a new design pattern which meets the following needs:

+ eventO ccured(s ign : S tring, para : O bject) : S tate + execu teEntr y(sign : String) + exec uteD o(sign : String) + execute E xit(sign : S tring )

+ eventO ccured(s ign : S tring, para : O bject) : S tate 1..* T r a n si ti on

- transitions

- states # next Tran sition s 1 - n extS tate

*

1

*

1 - even tSign : String + evalu ateG ua rd( para : O bject) : boolean 1 + even tO ccu red( para : O bject) : S tate

Figure 4 Structure of Statechart Pattern S ta te c ha rt Pa tte r n

S tatechart D iagram

C lass D iagram

- The pattern has a mechanism for state-transition execution including transition in substates. - The pattern can be easily imp lemented to the executable Java code by referring to a mapping rule. - The implemented executable Java code can be easily modified by the system designer later.

D e fi ne C o nte xt-s pe c ifi c Inte rfa c e s

C ontext-specific Interfaces

M a p p in g Ru l e b e tw e e n D e s i g n M od e l a n d Ja va C o de A d d M e th o ds o f Inte rfa c e s i nto C o n te x t

D e s c r ib e L i n k s b e tw e e n S ta te a n d T ra n s i ti on

R elatio nsh ips betw een S tate and Transition

E x tr a c t E ve nts a n d T h e ir Pa r a m e te r s

T r a n s f o r m fr o m De sign M ode l to J a v a C o d e

D e s i g n M od e l

E ven t S tring s an d P aram eter C lasses

Figure 5 Implementation Methodology of Statechart Diagram with Statechart Pattern

3.3 Structure of Statechart Pattern Figure 4 shows the structure of the Statechart pattern which is proposed in our study. The classes and interfaces in Figure 4 are defined as follows:

- GuardStrategy and ActionStrategy represent two logics in order to evaluate conditions and execute actions according to occurred events.

- Context is the class which has the dynamic behavior described by the statechart diagram. The object has one StateMachine object. - StateMachine has two sets of states and transitions. The object is a either of statechart diagram, sequential substates, or one substates in concurrent substates. - EntryActions, DoActivities, and ExitActions represent three sets of entry-actions, do-activities, and exit-actions respectively. Each action in a state is defined in these interfaces as an empty method. - Guards and Actions represent two sets of guardconditions and actions. Each condition and each action in transition are defined in these interfaces as an empty method. - EntryActionStrategy, DoActivityStrategy, and ExitActionStrategy represent three logics in order to execute actions according to current states.

3.4 Implementation Methodology of Statechar t Diagram with Statechart Pattern Figure 5 shows the implementation methodology of statechart diagrams with the Statechart pattern. It consists of the following five processes: 1) Defining the five context-specific interfaces, 2) Adding all the methods of the defined interfaces to the class Context, 3) Describing all the relationships between state and transition, 4) Extracting all the events and their parameters, and 5) Tra nsfor min g fr o m the d e s ig n mod e l to the Java code by referring to the mapping rule.

213

public class SensorA extends Sensor implements ActionStrategy, ActionsOfSensorA { StateMachine stateMachine; public SensorA(String name) { stateMachine = new StateMachine(name); stateMachine.createSequentialStateMachine( ” Normal Operating”); stateMachine.createState(” Abort ”); stateMachine.createSequentialStateMachine( ” Normal Operating”, “ Running”); stateMachine.createState(” Running”, “ Initializing”); // ........ stateMachine.connectState(”Normal Operating”, “ Abort”, “ Abort”); stateMachine.connectState(”Abort”, “ Recovered”, “ Recover ”); // ........ stateMachine.setInitialState(” Normal Operating ”); stateMachine.setInitialState(” Running”); stateMachine.setInitialState(” Initializing”); } public void executeAction(String event, Object parameters) { if(event.equals(” OperateA”)) specificActionA(event, parameters); else if(event.equals(” OperateB”)) specificActionB(event, parameters); else return; } public void specificActionA(String event, Object parameters) { // Describe Specific Action A } public void specificActionB(String event, Object parameters) { // Describe Specific Action B } }

No r m a l O p e ra tin g

A bo rt

Ru n n i n g

O per ateA / Sp ecif ic A ction A A b or t

Ini ti a li zi ng O pe r a ti n g

Re c o ve re d

O per ateB / S pecific A ction B

R ecove r

Figure 6 An Example of Statechart Diagram Table 2 Mapping Rule between Design Model and Java Code State an d S ubs ta tes

N ode in Tree S truc ture of S tates

S tate O bject and S tate M achin e O b ject

Trans ition

Tran sition R elations hip betw e en S tates

T ransition O bjec t

Initial P s eudostate

N ode in Tree S truc ture of S tates

V ariable of C lass S ta teM ach ine (i. e. S tate O bject)

F in al State

N ode in Tree S truc ture of S tates

S tate O bjec t

E vent and Its P aram eter

E ven t S trin g an d C lass of P aram eters

E ven t S trin g an d C lass of P aram eter s

G uar d C ondition

Em pty M etho d of Interface G ua rds

Im plem ente d M eth od of class C onte xt

A ction (In c luded in side State)

Em pty M etho d of Interfaces A ctions, etc.

Im plem ente d M eth od of class C onte xt

Figure 7 An Executable Java Code of Statechart Diagram m a nages

1 D e vi c e

As an example of implementation of a statechart diagram, we implement the statechart diagram shown in Figure 6 by applying the implementation methodology. In Figure 5, each process can be divided into the following steps:

- d evice

1

1

- device M anager 1

D e vi c e M a n a ge r

Sensor

Ac tu a to r

C o n tro ller

SAC

C o m p o n en ts in co m m o n w ith D e vice

1.1) Define the five context-specific interfaces. 1.2) Define each guard condition and each action as a method, and then add them to the inter face Guards and Actions. 1.3) Define each action in all the states as a method, and then add them to the interfaces EntryActions, DoActivities, and ExitActions. 2.1) Add the methods of all the strategy interfaces to the class Context. 2.2) Add the methods of all the interfaces defined in the first process to the class Context. 3.1) Identify the tree structure of states, all the transition relationships between states, and all the initial pseudostates. 4.1) Extract event names from all the transitions. 4.2) If an event has one or more parameters, define a set of parameters as a class. 5.1) Transform from the design model to the Java code by referring to the mapping rule shown in Table 2.

A b stra c t C la sse s fo r In h e rita n ce

1

Ac tive E le m e n t

(a) SEMI Common Device Model m a nages

1 D e vi c e

- d evice

D e vi c e M a n a ge r

C o m p o n en ts in co m m o n w ith D e vice

SAC

A d d iti o n a l C o n c r ete C la sse s

1

C o n c re te Sensor

C o n c re te A c tu ato r

C o n c re te C o n tro ll e r

Sensor

Ac tu a to r

C o n tro ller

Ac tive E le m e n t

A b str a c t C la sse s

(b) Direct Composition of Concrete Classes by Class Device

Figure 8 Common Device Model and Extended Model become ambiguous. In order to solve this problem, an extended model can be considered as shown in Figure 8 (b). Because the class Device manages the component classes directly, the configuration of the components will be clear. However, the system designer must define the association between the class Device and the component class. The system designer must implement the procedure for creating the component objects into the class Device’s constructor. In order to solve these problems, the system designer needs a design pattern which meets the following requirements:

Figure 7 shows the executable Java code of the statechart diagram shown in Figure6. 4. Device-Constructor Pattern In order to construct the static structure of a device model, we describe the Device-Constructor pattern and the construction methodology of the device model with it.

1) The pattern can define new component classes without associating between the class Device and them. 2) The pattern provides interfaces for creating the component objects without depending on the kinds of components and the numbers of their objects. 3) Interfaces provided by the pattern are very simple.

4.1 Previous Design Patterns Figure 8 (a) shows the common device model. When the component class inherits any one of the three abstract classes, the configuration of the device components may

214

*

D e vi c e

+ + + +

clon e() : D evice createS en s or(key : K ey, n : int) createActuator(key : Key, n : int) createC on troller( key : K ey, n : int)

1

- sensors *

A E C o n ta i ner

AEFactory f = AEFactory.getSensorFactory();

1

Sensor s = new SensorA(); // Regist class SensorA f.add(new Key(”SensorA”), s); // Key String for SensorA

1 + clone() : A E C ontainer + addElem ent()

1 1

1 {xor}

- key : K ey = null - n Elem ent : int = 0

1 - deviceM an ager

1

- sac 1..*

D e vi c e M a na ge r

Actuator a = new ActuatorA(); // Regist class ActuatorA f.add(new Key(”ActuatorA”), a); // Key String for ActuatorA (a) Registration Procedure of Concrete Classes Device device = new Device();

- elem ents

SAC Ac tive E le m e n t

+ clone() : D e vic eM anager

+ clone() : S A C

D ev ic e’s C o m p o n en ts

Ab stra ct C la s s e s

Sensor

Ac tu a to r

C o n tro ller

+ clone() : S en s or

+ clone() : A ctuator

+ clone() : C ontro ller

C o n c re te S e n s o r

C o n c re te A ctu a to r

C o n c re teC o n tro l le r

+ clone() : Senso r

+ clone() : Actu ator

+ clone() : C ontroller

U se r- d e fi n e d C o n c re te C la s s e s

1

1

1

A E F a cto ry

+ + + + +

getS ensor F actory() : AEF a ctory getA ctuato rF actory() : A E F ac tory getC ontrollerF ac tory() : A E F actory add(k ey : K ey, pr ototype : A c tiveE lem en t) clone(k ey : K ey) : A ctiveE lem ent

1 - sensor 1 F actory - actu ator 1 F actory - controller F actory

Figure 9 Structure of Device-Constructor Pattern D yn am ic B eh avior D escriptions of C om pon en ts of D evice

UML

// create three ActuatorA objects device.createActuator( new Key(”ActuatorA”), 3); // Key String number of objects (b) Construction Procedure of Device Object

{xor }

- sensorF actory : AEF actory = null - actuatorF acto ry : A E F actory = null - controllerF actory : AE F actory = null

C re ati o n F ac to ry o f C lo n es o f S en so r , A ct u ato r, an d C o n tro ller O b j ec ts

// create two SensorA objects device.createSensor( new Key(”SensorA”), 2); // Key String number of objects

S tatechar t P attern

D e fi n e c l a s s e s , a n d c o m p i le th e m

C onc rete C las ses

Figure 11 Registration Procedure of Concrete Classes and Construction Proccedure of Device Object The Device-Constructor pattern meets the requirements described in section 4.1 by the following mechanisms: - The object of the class AEFactory contains the objects of each concrete class with a key string. - The object of the class AEContainer contains all the objects of a particular concrete class. - In order to create device components, the system designer must d escr ib e the seq ue nce o f clas s Device methods with the key string of the concrete class and the number of objects as two arguments.

D e vic e C on s tru c tor p a tte rn

Java

Re gi s t cl a s s e s i nto AE F a c to ry o bj e c t

C om pon en ts of D evice K eys of E ach C oncrete C las s

UML

D C S S im ulator O bjec t D iagram of D evice O bject

Java Code

Java D esign AE C o n ta in e r o bj e c t D esign D e vic e o b je c t

M odelin g Tool

Figure 10 Construction Methodology of Device Model with Device-Constructor Pattern 4.2 Structure of Device-Constructor Pattern Figure 9 shows the structure of the Device-Constructor pattern, which is proposed in our study. In the DeviceConstructor pattern, the classes are defined as follows:

4.3 Construction Methodology of Device Model with Device Construtor Pattern Figure 10 shows the construction methodology of the device model with the Device-Constructor pattern. As an example of the device model, we consider a device model which consists of two sensors called Sensor A, and three actuators called Actuator A. The methodology consists of the following four processes: 1) By referring to the device components, define each component as a concrete class of the abstract classes Sensor, Actuator, and Controller, and then compile them. The dynamic behavior of the concrete class is implemented by using the Statechart pattern.Then allocate unique strings to each concrete class. 2) By referring to the defined concrete classes and their key strings, define the registration procedure of the concrete classes into the AEFactory object, as shown in Figure 11 (a). 3) In order to define the static structure of the device model, design the AEContainer objects which contain all the objects of a particular concrete class by drawing an object diagram as shown in Figure 12. 4) By referring to Figure 12, define the construction procedure of Device object shown in Figure 11 (b).

- Device represents the device model defined by the SEMI Common Device Model. - AEContainer represents the container for all the objects of a particular concrete class. - AEFactory represents the factory for creating the cloned objects of the concrete classes. - ConcreteSensor, ConcreteActuator, and ConcreteController represent the concrete classes of three abstract classes Sensor, Actuator and Controller. The Device-Constructor pattern partially extends the following recent design patterns; Abstract Factory, Factory Method, Prototype, Singleton, and Composite.

215

dev ic e: D evice

C o n ta in ers o f C o m p o n en ts

actuators[0 ] : A E C on tainer

sensor s[0] : A E C ontainer key = K ey(” S en sor A ”) nE lem ent = 2

elem en ts[0] : S en sorA

V A V D e vice

key = K ey(”Ac tuatorA”) nElem ent = 3

elem en ts[1] : S en sorA

elem en ts[0] : A ctu ator A

elem en ts[1] : A ctu ator A

S p a ce C o m fo rt C o n tro ller D e vic e

L ist o f D e v ic e s

elem en ts[2] : A ctu ator A

Sp ace T em p e ra tu re D e v ic e

D e vice C o m p o n en ts

Figure 12 Object Diagram of Example of Device Model 5. Modeling Tool and DCS Simulator In order to construct device models in the DCS and simulate its dynamic behavior, Motorola Japan Inc. has developed the modeling tool of the device model and the DCS simulator. In the modeling tool, the DeviceConstructor pattern is used for defining the static structure of the device model, and the Statechart pattern is used for implementing the dynamic behavior of the device model as the Java code. Figure 13 shows the snapshot of the modeling tool. In Figure 13, five kinds of device models are modeled, and are registered into the list of devices. By modeling the device models actually, we confirmed that two design patterns were very useful for rapidly developing the device models. Figure 14 shows the snapshot of the DCS simulator. The system designer can observe the performance of the network and the log of packets. Where the protocol of LonWorks is implemented as the network protocol of the DCS. By comparing the log of packets with the message sequence among the device models, we confirmed that two design patterns were very useful for simulating the dynamic behavior of the control network with the device models. By embedding two design patterns into the modeling tool and the DCS simulator, the period of time required for developing these applications was enormously shortened from four months to two months. Furthermore, because the newly defined component classes are imported into the DCS simulator alone, we consider that the efficiency of device modeling in the modeling tool is very high.

S w i tc h D e vice AH U D e v ic e

Figure 13 A Snapshot of Modeling Tool

L o g o f P ac kets P e rfo r m a n c e o f N etw o rk

M e ss a g e S e q u en c e am o n g D e vi ce s

Figure 14 A Snapshot of DCS Simulator

References [1] Piggin, R., Young K., and McLaughlin, R., “Current Fieldbus Standards Situation - A Europian View”, Assembly Automation, Vol. 19, No. 4, 286-289, 1999. [2 ] SEMATECH, “CIM Application Fr a mework, Specification 1.2”, 1995. [3] OSE, “OSEC Architecture Version 2.0”, 1996. [4] SEMI, “SEMI E54.1-0298 Standard for Sensor/ Actuator Network Common Device Model”, 1996. [5] Object Management Group, Inc., “OMG Unified Modeling Language Specification Version 1.3”, Object Management Group, Inc., 1999. [6] Gamma, E.et al., “Design Patterns Elements of Reusable Object-oriented Software”, Addison Wesley Longman, Inc.,1995. [7] Grand, M., “Patterns in Java - A Catalog of Reusable Design Patterns, Illustrated with UML, Volume 1”, John Wiley & Sons, 1998. [8] Harel, D., and Politi, M., “Modeling Reactive Systemswith Statecharts”, McGraw-Hill, 2000. [9] Douglass, B. P., “Real-Time UML - Developing Efficient Objects for Embedded Systems”, Addison Wesley Longman, Inc., 1998.

6. Conclusions The conclusions of our study are summarized as follows: 1) We have proposed two design patterns for modeling a DCS. The Statechart pattern defines classes and the state-transitio n executio n mechanism for realizing the dynamic behavior of devices. The Device-Constructor pattern defines classes and their instantiation mechanism for realizing the static structure of devices. 2) We have discussed the systematic implementation procedures to bridge from those patterns to the executable Java code of the simulation model. 3) We have con fir med the effectiveness of o ur approach based on these patterns through actually developing of an in-house Java-based DCS simulator for the building automation.

216