system-level modeling and simulationof an elevator...

Center for Embedded Computer SystemsUniversity of California, Irvine

System-Level Modeling and Simulationof an Elevator Control System

Daniel Castellanos, Rainer Domer

Technical Report CECS-07-04June 25, 2007

Center for Embedded Computer SystemsUniversity of California, IrvineIrvine, CA 92697-3425, USA

(949) 824-8059

{dcastell, doemer}@uci.eduhttp://www.cecs.uci.edu/

http://www.cecs.uci.edu/



Technical Report CECS-07-04June 25, 2007


(949) 824-8059

{dcastell, doemer}@uci.eduhttp://www.cecs.uci.edu

Abstract

The design complexity of embedded systems is rapidly increasing as more functionality andhigher performance is demanded. As a result, the design process must be broken down intomultiple steps to achieve system requirements. In this paper, we employ such a design process bypresenting a case study for the modeling and simulation of an Elevator Control System (ECS).Our system model combines instantiations of Elevator Control Units (ECU) which communicatethrough a central broadcast channel implemented by a Controller Area Network (CAN) bus.Our generic model was specified using a System Level Design Language (SLDL), SpecC. Inparticular, our ECS was customized to simulate the behavior of four elevator shafts operatingin a ten story building. The model was successfully specified and simulated at three abstractionlevels: the specification, transaction, and bus functional level.

http://www.cecs.uci.edu

Contents1 Introduction 2

1.1 Case Study: An Elevator Control System . . . . . . . . . . . . . . . . . . . . . . . 31.2 Paper Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Elevator Control System 42.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Modeling ECUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Door Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Display Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.3 Panel Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.4 Motor Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.5 Main Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1 ECU Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Model Validation 103.1 Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Use Case Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Conclusion 13

5 Acknowledgement 13

References 13

A Appendix 15A.1 SpecC Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

A.1.1 ecs.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15A.1.2 ecs.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16A.1.3 ShaftUnit.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17A.1.4 FloorDoor.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19A.1.5 CarDisplay.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

A.2 Test Bench and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24A.2.1 TestBench.sc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24A.2.2 Simulation Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

i

List of Figures1 Abstraction Levels in Embedded System Design [2]. . . . . . . . . . . . . . . . . 32 Car and Floor Door Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Car and Floor Display Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Car and Floor Panel Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Motor Controller Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Main Controller Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 The Floor and Car Unit Hierarchical Structure. . . . . . . . . . . . . . . . . . . . 88 ECS Generic Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Elevator Control System Test Configuration. . . . . . . . . . . . . . . . . . . . . . 12

ii

List of AcronymsBFM Bus Functional Model. A wire accurate and cycle accurate model of a bus.

CAN Controller Area Network. A serial communications protocol with a focus for automotiveapplication.

ECS Elevator Control System. An embedded system that models an elevator system by instantiat-ing multiple elevator control units.

ECU Elevator Control Unit. An individual system that performs a specific task for an elevator.

SLDL System Level Design Language.

SOC System-on-Chip.

TLM Transaction Level Model. A model of a system in which communication is described astransactions, abstract of pins and wires.

1




{dcastell, doemer}@uci.eduhttp://www.cecs.uci.edu

June 25, 2007

AbstractThe design complexity of embedded systems is rapidly increasing as more functionality and higherperformance is demanded. As a result, the design process must be broken down into multiple stepsto achieve system requirements. In this paper, we employ such a design process by presenting acase study for the modeling and simulation of an Elevator Control System (ECS). Our system modelcombines instantiations of Elevator Control Units (ECU) which communicate through a centralbroadcast channel implemented by a Controller Area Network (CAN) bus. Our generic model wasspecified using a System Level Design Language (SLDL), SpecC. In particular, our ECS was cus-tomized to simulate the behavior of four elevator shafts operating in a ten story building. The modelwas successfully specified and simulated at three abstraction levels: the specification, transaction,and bus functional level.

1 IntroductionThe massive success of portable electronic devices has initiated a demand for complex and compu-tationally intensive embedded systems. The time to market and functionality of these devices hasbecome highly competitive. Companies urge system designers to develop better systems in a shortertime. Consequently, the design process becomes a greater challenge.

2

http://www.cecs.uci.edu

Figure 1: Abstraction Levels in Embedded System Design [2].

Under these circumstances, designers model a System-on-Chip (SOC) using multiple levels ofabstraction. Figure 1 describes the typical design flow of an embedded system. First, a systemmust be proposed with well-defined requirements which define the system behavior. This forms aspecification model. Models are further refined until a synthesizable representation is developed.Embedded systems are also designed by exploiting hierarchy. Hierarchical design is critical withlarge systems because it reduces complexity and eases debugging.

System Level Design Languages (SLDL), such as SpecC [1] and SystemC [3], provide a viablesolution to modeling and designing highly complex systems. SLDLs assist the design flow describedin Figure 1 by supporting modular design, executability, synthesizability, and simplicity.

1.1 Case Study: An Elevator Control SystemThis paper will describe the modeling process of an Elevator Control System (ECS) using SpecC.The proposed system will act as a set of elevators typically found in a high-rise building. The ECSwill be a distributed embedded system, consisting of a set of communicating Elevator Control Units(ECU) implemented as a System-on-Chip (SOC). Our design will be described at roughly the firstthree levels illustrated in Figure 1. In addition, the ECS will be modeled as a set of Elevator ControlUnit (ECU)s, each ECU representing a subcomponent of the system. A hierarchy of subcomponentswill be modeled and validated individually.

1.2 Paper OrganizationThe following section describes the design of the ECS. Our case study will design the ECS usingthree levels of abstraction: the specification model, the Transaction Level Model (TLM), and theBus Functional Model (BFM). The behavior of each ECU is described separately. Section 3 willthen discuss the simulation environment and parameters used to validate the ECS model.

3

2 Elevator Control SystemIn this section, we will describe the design of an Elevator Control System (ECS). The purpose ofthis section is to give some insight on how a large system can be broken into subsystems and incor-porated to work together. The design process can be described in four parts. First, each subsystem isspecified and modeled. Second, a hierarchical structure is constructed using subcomponents. Third,a communication channel is integrated to allow subsystems to communicate with each other. Lastly,each subsystem is integrated and modeled as one system.

2.1 System OverviewThe ECS is modeled as a set of multiple ECUs, all running in parallel. All ECUs are individualsystems, but behave as subsystems embedded within the ECS. Each ECU is responsible for a distincttask within the system. The design complexity is reduced by modeling each ECU separately. AllECUs are typical of an elevator system. Table 1 lists the eight ECUs modeled.

Table 1: Elevator Control Unit DescriptionsElevator Control Unit Functionality

1 Floor Panel Panel at each floor and each shaft with up-down controls2 Floor Display Display of current floor and direction at each floor3 Floor Door Control unit to open-close doors at each floor4 Car Panel Panel in each car with request controls5 Car Display Display of current floor and direction in each car6 Car Door Control unit to open-close door at each car7 Motor Controller Control unit for the motor atop each shaft8 Main Control Unit Central control to control the entire ECS

2.2 Modeling ECUsA specification model requires well defined requirements and behaviors. The ECUs are carefullymodeled using these requirements. The ECS consists of eight distinct ECUs. The structure andbehavior of each ECU is described below.

2.2.1 Door Units

The floor and car door units maintain control of the elevator doors. Their structure and behavior aresimilar, but placed differently within the ECS. For example, an elevator shaft can consist of onlyone car door and several floor doors, one for each floor. The task of the door units is simply to openand close the door when signaled. The structure of these systems consists of an output port to signalclose or open. These events are triggered by listening to a bidirectional communication port. Figure2 illustrates the structure of the door units.

4

(a) (b)

(a) (b)

Figure 2: Car and Floor Door Units.

2.2.2 Display Units

Floor and car display units are distributed similarly as the door units. A floor and car display systemcontinuously displays the location and the direction of movement, if any, on a monitor. These twosystems consist of three output ports. One to indicate the floor number, and two for direction.Direction can be identified with only one port, but a non-moving state requires the addition of thesecond port. The internal behavior is also triggered by a bidirectional communication port. Figure 3shows the structure of the floor and car display units. When an update is received, the display unitsare updated accordingly.

(a) (b)

(a) (b)

Figure 3: Car and Floor Display Units.

2.2.3 Panel Units

The floor panel’s purpose is to dispatch elevator requests from outside the elevator. It consists oftwo buttons that act as inputs to specify the direction of the request. Floor panels are typicallydesigned with a LED light as a means for acknowledgement. Therefore, a floor panel unit can bemodeled with two input ports and two output ports for requests and LEDs respectively. Internally,

5

the floor panel constructs a message with the request and sends it out. A floor request panel receivesmessages to update the LED request buttons. Therefore, a bidirectional port is also required forcommunication purposes.

(a) (b)

(a) (b)

Figure 4: Car and Floor Panel Units.

The structure of the car panel is different compared to the floor panel. Figure 4 shows thestructural differences. In the car panel, instead of buttons to identify direction, the buttons representfloor numbers. The floor numbers are represented by a bus-like wired port. In essence, the inputport is a bundle of wires, where each wire represents a floor number. A similar output port is neededfor each LED light used for acknowledgement (as with the floor panel). The port is continuouslymonitored. A state change in any of the wires triggers a request. The bidirectional communicationport is used to send out requests and to update the state of the LED lights for each button.

2.2.4 Motor Controller

The motor controller unit manages the position of the elevator car. Structurally, it is formed withtwo output ports used to enable/disable the motor and to indicate the direction of movement. Figure5 shows the structure of the motor controller. The output ports are designed as inputs to the motorthat moves the elevator. It must work closely with the motor to identify its location. The motorcontroller must also work closely with the main control unit. This interaction is conducted throughthe bidirectional communication port. The motor controller and the main control unit communicatethrough this port to ensure requests are completed. By request of the main control unit, the motorcontroller determines the direction to move in order to satisfy the request. It disables the motorwhen it has moved to a different floor to allow the main controller to determine if it should continuemoving. However, if the elevator is located at the requested floor, it composes a series of messagesto indicate its floor location, its direction and announces it has arrived at a requested floor.

2.2.5 Main Controller

The main control unit is the most complex ECU. It is the centralized control element of the ECS.It works closely with all processing elements by delegating and handling all requests that arrive in

6

Figure 5: Motor Controller Structure.

the system. The motor controller and main control unit process most of the control of the ECS.The main controller structure, however, is much simpler. Figure 6 shows the structure of the maincontroller. It consists of only one bidirectional communication port. In contrast, the behavior ismore complex. The overall range of supported features that are designed in each ECU can varyfrom very simple to highly complex. A main control unit must keep track of requests and managestability. The focus of this study is to properly model and describe the basic behavior of an elevatorcontrol system. Therefore, the main control unit only supports essential features.

Figure 6: Main Controller Structure.

The main control unit performs three basic tasks. First, it keeps track of all requests made by thefloor and car panels. It uses this information to verify if a request has been completed. Second, it isresponsible for making decisions and assigns commands. In a request initiated by a floor panel, themain control unit determines which elevator will service the request. Therefore, the main controlunit also monitors every elevators floor location. Lastly, it is also responsible for notifying all ECUsonce a request has been completed.

Our implementation of the main controller is primitive in design and imposes some limitations.For example, car requests have priority. Therefore, if all shafts are active, no elevator car will everarrive to a floor request. If multiple car requests are made in a car shaft, only the first request isserviced. Clearly, these limitations have solutions which can be added in future work. Ultimatelythe design of the main controller can be expanded to support a multitude of features. For simplicitysake, these features are omitted from this implementation.

7

2.3 System IntegrationSystem integration issues can be simplified if a hierarchical structure is implemented. The modular-ity of these models also makes adding features easier. In the ECS, multiple units can be instantiated.This requires the ECU structures to include ports for identification purposes. To support this, theport can be declared with a hardwired identification number. For example, a car panel in elevatorthree can have a three as a shaft ID. Furthermore, a floor panel will also need an identifying floornumber. This can be modeled by adding yet another port dedicated to identify the floor ID. In theECS two main hierarchical components are grouped, the floor and car units. A floor unit consists ofa panel, display, and a door. Similarly, a car unit is composed of these units as well. These structuresare illustrated in figure 7. For clarity, the ports unique to each structure have been omitted, showingonly the identification and communication port.

Figure 7: The Floor and Car Unit Hierarchical Structure.

Hierarchical modeling can be further applied. The car unit and floor unit can be subcomponentsof a new structure, a shaft unit. In this module, the motor control unit is also integrated withinthe shaft unit. An ECS system can modeled by instantiating a shaft unit and a main controller.Multiple elevators can be declared by instantiating multiple shaft units. Therefore by implementinga hierarchical model, a generic model is designed.

8

2.3.1 ECU Communication

It is clear that ECUs heavily rely on a bidirectional communication port. This is the primary com-munication medium of all ECUs. The ECS model employs a broadcast channel which in our im-plementation is a Controller Area Network (CAN) bus [4]. The CAN bus is a widely implementedbroadcast communication protocol that is widely adopted for automotive purposes. The specifica-tion model is then refined to a Transaction Level Model (TLM). The TLM also utilizes the CANbus model as a communication channel. In fact, each ECU is wrapped around a structure that im-plements the MAC link channel. In Figure 7, the bidirectional port has been replaced with a channelinterface.

Further refinement of the ECS can be applied using the CAN bus model. In the Bus FunctionalModel (BFM) the timing of bus can be properly modeled. The structure of the BFM becomesslightly different. A communication channel is no longer shared by all subcomponents. Instead, theCAN bus communication port is embedded within each ECU and connected via a bus. This modelcan accurately simulate the timing of the ECS.

The CAN bus supports the broadcast of messages to all units within the ECS. A message struc-ture is defined and supported by all ECUs. Nine message types were designed for ECU commu-nication. Each message is broadcast to all ECUs (except for the one who created the message).The ECUs continuously listen through the communication channel for any incoming messages. Al-though, all ECUs receive every message, each unit is responsible for identifying if it is the properdestination. The shaft and floor identification number are compared to those specified in the mes-sage. If a message is not addressed to a specific ECU, it is simply ignored. The following are thenine messages an ECU can receive and/or transmit.

Floor Request A floor request message is created by a floor panel as a response to a user. Themessage consists of the floor ID and the direction. It is used by the main control unit andother floor panels sharing the same floor ID.

Car Request A car request is similar to a floor request, but originates from within the elevator.Therefore, the elevator shaft ID is specified. This message consists of a shaft ID and a desti-nation floor number. This message is destined to the main control unit.

Open Door An open door request is created by the motor controller when it is signaled by themotor that it has arrived at a requested floor. The message is composed of the floor ID andshaft ID. It signals both the car door and the floor door units.

Close Door A close door message, does as named, closes the car and floor doors. Its messagecontents are the same as an open door message.

Car Go To The car go to request is a message created by the main control unit. This message iscreated in response to a floor or car request message. This message consists of a shaft ID, andfloor ID and is sent to the motor controller.

Car Position This message allows the car/floor ECUs to display the current location of an elevator.The message also indicates the direction movement (or if it is stationary). The message is

9

transmitted by the motor controller and is awaited for by the car/floor panels and the maincontrol unit.

Car Arrived A car arrived message informs the main controller an elevator has arrived at a re-quested destination. This message sent out by the motor controller. The main control unituses this message to update the status of pending requests.

Floor Request Granted Upon completion of a request, the main control unit informs the floorpanels to update their LED ports.

Car Request Granted Similar to a floor request granted message, but destined to the car panelLED ports.

2.4 SummaryThis section has described how each ECU was modeled. The hierarchical design allows reusabil-ity by grouping similar components into one. The CAN bus provides an efficient communicationmedium used to broadcast messages to all ECUs. A complete ECS system was modeled.

In the following section a validation environment is constructed and simulated.

3 Model ValidationIn this section, the validation method is described. The generic model of the Elevator ControlSystem (ECS) is instantiated and simulated as four elevator shafts in a ten story building. A testbench was written to ensure the ECS behaves as expected. The following section will describe thesimulated behavior, the ECS testing structure, and simulation environment.

3.1 Simulation EnvironmentThe ECS was designed to provide a customizable simulation environment. Specifically, it allows theuser to modify the number of floors and the number of elevator shafts. The core of the ECS modelis illustrated in Figure 8. Note that the diagram uses the car unit and floor unit modules presentedin Section 2. In addition, this figure describes the ECS system with the CAN bus Transaction LevelModel (TLM). The CAN bus is distributed to each ECU. For simplicity, the input and output portsof each individual ECU have been omitted.

For simulation purposes, a variable number of floor units and shaft units can be declared. Thenumber of floor units corresponds to the number of floors desired. Likewise, the number of shaftunits specifies the number of elevator shafts. Our test model consists of ten floor units and fourelevator shafts. All ECUs managed by one main control unit which communicate through the samecommunication channel.

In Figure 9 a general overview of the testing structure is shown. The structural differencesbetween a TLM and BFM model are clearly shown. To control the simulation environment, thepanel ECUs were disabled to prevent them from creating their own requests. A test bench unit wasintegrated and commands were injected through the CAN bus.

10

Figure 8: ECS Generic Model.

11

Figure 9: Elevator Control System Test Configuration.

3.1.1 Use Case Description

The ECS initial conditions establish each elevator on the first floor. There are only two ways torequest elevator service, that is, through the car or floor panels. Let us assume a user requests to godown while currently at the 5th floor. The user presses the down button. This event triggers the floorpanel to light up the LED button. A floor request message is composed and broadcast. All ECUs,except the floor panels and main control unit, discard this message. Only the floor panels with thesame floor ID use this request and enable their LED buttons. The main control unit, however, playsa more vital role. It assigns the elevator to service the request. It follows by transmitting a car goto message. The motor controller proceeds as signaled by the request. The motor controller unitdetermines the current position of the elevator shaft, and, in this example, it ascends. As it is inmotion, it generates a series of car position messages to update the state of the floor and car displayunits. In addition, the main control unit is informed as the elevator transitions from one floor to thenext. As it arrives to the 2nd floor, the main control unit verifies if any other floor requests havebeen issued at the new floor. A new car go to message is re-issued either with the same request or anew one. This process continues until the elevator arrives at the initially requested floor. The motorcontroller sends a message to open the doors and informs the main controller to clear its request.The doors close shortly after.

For testing purposes, a monitor was connected to each ECU output port. This allows for quickdebugging and verification that every message is managed correctly and the system behaves asintended. A printout of the monitor is shown in the Appendix. The printout shows the response ofeach ECU as it progresses until the request completed.

In the event that a request is made from inside the elevator, a car request is produced. Theprocess is similar as requesting service by using the floor. Inside however, the car panel directly

12

defines the elevator and the floor number destination. The main controller then keeps track of thisrequest and prevents any floor requests from being issued to this elevator. It is evident how the maincontroller plays a critical role in maintaining stability. The ECU exchange messages as describedearlier.

The example described is a simple way to show functionality and how the model works overall.The model, however, was tested using multiple commands with elevators running in parallel. Thetest bench and results from the simpler simulation can be referenced in the Appendix.

Overall, the simulation run successfully validates the ECS model. It is important to note thatthe simulation of the BFM abstraction took considerably longer than the TLM. Therefore, the TLMmodel was used as the primary model to validate our system. It is reasonable to assume that thesame behavior can be reproducible based on the results of the BFM.

4 ConclusionThis paper has described a case study for the modeling of an Elevator Control System (ECS) using aSystem Level Design Language (SLDL). The ECS was designed and modeled using a set of ElevatorControl Units that interact via a central broadcast communication channel. The communicationchannel is an abstract model based on the Controller Area Network (CAN) bus. The ECS wasmodeled at three abstraction levels: the specification model, the Transaction Level Model (TLM),and the Bus Functional Model (BFM).

The ECS was designed to provide a configurable simulation model. The ECS model was vali-dated by simulating four elevator shafts operating in a ten story building. The simulation of the ECSexhibited the expected behavior.

The simulation results also provide some insight into possible future work. The main controlunit provides ECS with the basic control to function, but imposes some limitation. In addition,safety considerations were not considered in the design and could be added to the model in thefuture. Overall, the system model successfully describes an ECS.

5 AcknowledgementSome portions of our implementation rely on the results of the class EECS 298: System-on-ChipDescription and Modeling Winter 2006. In particular, portions of the implementations by ShinkoKawagoe and Seung-mok Yoo were reused.

References[1] Daniel D. Gajski, Jianwen Zhu, Rainer Domer, Andreas Gerstlauer, and Shuqing Zhao. SpecC:

Specification Language and Design Methodology. Kluwer, 2000.

[2] Andreas Gerstlauer, Rainer Domer, Junyu Peng, and Daniel D. Gajski. System Design: APractical Guide with SpecC. Kluwer, 2001.

13

[3] Thorsten Grotker, Stan Liao, Grant Martin, and Stuart Swan. System Design with SystemC.Springer, 2002.

[4] Gunar Schirner and Rainer Domer. Abstract communication modeling: A case study usingthe can automotive bus. In Proceedings of the International Embedded Systems Symposium,Manaus, Brazil, August 2005.

14

A AppendixA.1 SpecC SourceSelected SpecC Source has been provided below.

A.1.1 ecs.sh

# i n c l u d e <sim . sh>

# d e f i n e NUM FLOORS 10# d e f i n e NUM SHAFTS 4

/ / Clock p e r i o d f o r t h e CAN 0 . 2 m i c r o s e c −> 500MHz# d e f i n e CAN CLK PERIOD 200000 u l l# d e f i n e BUFFER 100

enum ECSMSG TYPE /∗ t h e t y p e s o f messages i n t h e ECS sys tem ∗ /{ECSMSG CAR REQUEST ,ECSMSG OPEN DOOR,ECSMSG CAR ARRIVED ,ECSMSG CAR POSITION ,ECSMSG FLOOR REQUEST GRANTED,ECSMSG CAR REQUEST GRANTED,ECSMSG CLOSE DOOR,ECSMSG CAR GOTO,ECSMSG FLOOR REQUEST

} ;

enum d i r e c t i o n {UP , DOWN, NONE} ;

s t r u c t ecsmsg /∗ d e f i n e our message d a t a t y p e ∗ /{

enum ECSMSG TYPE Type ;enum d i r e c t i o n m o v i n g d i r e c t i o n ;i n t S h a f t I D ;i n t F loo r ID ;boo l f l a g ;

} ;

15

/ / EOF e c s . sh

A.1.2 ecs.sc

# i n c l u d e <s t d i o . h># i n c l u d e < s t d l i b . h># i n c l u d e ” e c s . sh ”i m p o r t ” canBus / ne twork ” ;i m p o r t ” M a i n C o n t r o l l e r ” ;i m p o r t ” S h a f t U n i t ” ;i m p o r t ” Tes tBench ” ;

b e h a v i o r Main ( ){

/ ∗ (BFM) wi re f o r t h e CAN buss i g n a l r e s o l v e d b i t 4 [ 1 ] CAN DATA ; ∗ /

/∗ T r a n s a c t i o n Leve l Model (TLM) of t h e CAN P r o t o c o l ∗ /CanProtocolTLM c a n P r o t ;

/ ∗ (BFM) p u l l up r e s i s t o r f o r t h e CAN wi reP u l l U p R e s i s t o r canPu l lUp (CAN DATA ) ; ∗ /

/∗ I n s t a n t i a t e (BFM) ∗ //∗ S h a f t U n i t e l e v a t o r 1 ( 1 ,CAN DATA ) ;

S h a f t U n i t e l e v a t o r 2 ( 2 ,CAN DATA ) ;S h a f t U n i t e l e v a t o r 3 ( 3 ,CAN DATA ) ;S h a f t U n i t e l e v a t o r 4 ( 4 ,CAN DATA ) ;MainUnit c o n t r o l l e r (CAN DATA ) ;Tes tBench m e s s a g e p r o v i d e r (CAN DATA ) ; ∗ /

/∗ I n s t a n t i a t e (TLM) ∗ /S h a f t U n i t e l e v a t o r 1 ( 1 , c a n P r o t ) ;S h a f t U n i t e l e v a t o r 2 ( 2 , c a n P r o t ) ;S h a f t U n i t e l e v a t o r 3 ( 3 , c a n P r o t ) ;S h a f t U n i t e l e v a t o r 4 ( 4 , c a n P r o t ) ;MainUnit c o n t r o l l e r ( c a n P r o t ) ;Tes tBench m e s s a g e p r o v i d e r ( c a n P r o t ) ;

i n t main ( vo id ){

16

p a r {/ / ( BFM) canPul lUp ;

e l e v a t o r 1 ;e l e v a t o r 2 ;e l e v a t o r 3 ;e l e v a t o r 4 ;c o n t r o l l e r ;m e s s a g e p r o v i d e r ;

}

r e t u r n 0 ;}

} ;

/ / EOF e c s . s c

A.1.3 ShaftUnit.sc

# i n c l u d e <s t d i o . h># i n c l u d e < s t d l i b . h># i n c l u d e ” e c s . sh ”i m p o r t ” canBus / ne twork ” ;i m p o r t ” F l o o r D i s p l a y ” ;i m p o r t ” F l o o r P a n e l ” ;i m p o r t ” F loorDoor ” ;i m p o r t ” CarUn i t ” ;i m p o r t ” MotorUni t ” ;i m p o r t ” F l o o r U n i t ” ;

/∗ (BFM)b e h a v i o r S h a f t U n i t (

i n c o n s t i n t e l e v a t o r n o ,i n o u t s i g n a l r e s o l v e d b i t 4 [ 1 ] CAN DATA){

∗ /

b e h a v i o r S h a f t U n i t (i n c o n s t i n t e l e v a t o r n o ,I C a n P r o t c a n P r o t ){

/∗ I n s t a n t i a t e (BFM) −−There w i l l be 10 f l o o r s p e r s h a f t ∗ //∗ CarUni t s h a f t ( e l e v a t o r n o , CAN DATA ) ;

17

F l o o r U n i t f u n i t 1 ( 1 , e l e v a t o r n o , CAN DATA) ,f u n i t 2 ( 2 , e l e v a t o r n o , CAN DATA) ,f u n i t 3 ( 3 , e l e v a t o r n o , CAN DATA) ,f u n i t 4 ( 4 , e l e v a t o r n o , CAN DATA) ,f u n i t 5 ( 5 , e l e v a t o r n o , CAN DATA) ,f u n i t 6 ( 6 , e l e v a t o r n o , CAN DATA) ,f u n i t 7 ( 7 , e l e v a t o r n o , CAN DATA) ,f u n i t 8 ( 8 , e l e v a t o r n o , CAN DATA) ,f u n i t 9 ( 9 , e l e v a t o r n o , CAN DATA) ,f u n i t 1 0 ( 1 0 , e l e v a t o r n o , CAN DATA ) ;

M o t o r C o n t r o l l e r U n i t m o t o r u n i t ( e l e v a t o r n o , CAN DATA ) ;∗ /

/∗ I n s t a n t i a t e (TLM) ∗ /Ca rUn i t s h a f t ( e l e v a t o r n o , c a n P r o t ) ;F l o o r U n i t f u n i t 1 ( 1 , e l e v a t o r n o , c a n P r o t ) ,

f u n i t 2 ( 2 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 3 ( 3 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 4 ( 4 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 5 ( 5 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 6 ( 6 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 7 ( 7 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 8 ( 8 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 9 ( 9 , e l e v a t o r n o , c a n P r o t ) ,f u n i t 1 0 ( 1 0 , e l e v a t o r n o , c a n P r o t ) ;

M o t o r C o n t r o l l e r U n i t m o t o r u n i t ( e l e v a t o r n o , c a n P r o t ) ;

vo id main ( vo id ){

p a r {s h a f t ;f u n i t 1 ;f u n i t 2 ;f u n i t 3 ;f u n i t 4 ;f u n i t 5 ;f u n i t 6 ;f u n i t 7 ;f u n i t 8 ;f u n i t 9 ;f u n i t 1 0 ;m o t o r u n i t ;

18

}

}

} ;

/ / EOF S h a f t U n i t . s c

A.1.4 FloorDoor.sc

# i n c l u d e <s t d i o . h># i n c l u d e < s t d l i b . h># i n c l u d e < s t r i n g . h># i n c l u d e ” e c s . sh ”# i n c l u d e ” sim . sh ”i m p o r t ” canBus / ne twork ” ;

b e h a v i o r FDoorMonitor ( i n s i g n a l b i t [ 1 ] door ){


c h a r s t r i n g [BUFFER ] ;w h i l e ( 1 ){

w a i t door ;p r i n t f (”%d s e c \ t%l l u ps \ t \ t%s \ t F l o o r Door i s : %d\n ” ,( i n t ) ( now ( ) / ( 1 SEC ) ) , now ( ) , a c t i v e p a t h ( s t r i n g , BUFFER−1) ,( boo l ) door ) ;

}}

} ;

b e h a v i o r F loorDoor (i n c o n s t i n t FloorNo ,i n c o n s t i n t ShaftNo ,ICanMacLink l i n k ,o u t s i g n a l b i t [ 1 ] DoorOpen ){

vo id main ( vo id ){s t r u c t ecsmsg msg ;

/∗

19

I n i t i a l C o n d i t i o n s :Door s h o u l d be c l o s e d .∗ /

DoorOpen = 0 ; /∗ c l o s e d ∗ /

w h i l e ( 1 ){

l i n k . msgReceive (NONE, &msg , s i z e o f ( msg ) ) ;

s w i t c h ( msg . Type ){

c a s e ECSMSG OPEN DOOR :

i f ( ( msg . S h a f t I D == Shaf tNo ) && ( msg . F loo r ID ==FloorNo ) ) {DoorOpen =1;

}

b r e a k ;

c a s e ECSMSG CLOSE DOOR :

i f ( ( msg . S h a f t I D == Shaf tNo ) && ( msg . F loo r ID == FloorNo ) ) {DoorOpen =0;

}

b r e a k ;d e f a u l t :

b r e a k ;}

}}

} ;

/∗BFMb e h a v i o r F l o o r D o o r U n i t (

i n c o n s t i n t f l o o r i d ,i n c o n s t i n t s h a f t i d ,i n o u t s i g n a l r e s o l v e d b i t 4 [ 1 ] CAN DATA){∗ /

20

/∗TLM∗ /b e h a v i o r F l o o r D o o r U n i t (

i n c o n s t i n t f l o o r i d ,i n c o n s t i n t s h a f t i d ,I C a n P r o t c a n P r o t ){

s i g n a l b i t [ 1 ] ou t1 ;

/ ∗ (BFM)C a n P r o t o c o l T r c a n P r o t (CAN DATA, CAN CLK PERIOD ) ; ∗ /CanMacLink canMacLink ( c a n P r o t ) ;

F loorDoor f l o o r d o o r ( f l o o r i d , s h a f t i d , canMacLink , ou t1 ) ;FDoorMonitor fdoor m ( ou t1 ) ;


p a r {

/ ∗ (BFM)c a n P r o t ; ∗ /f l o o r d o o r ;fdoor m ;

}}

} ;

/ / EOF FloorDoor . s c

A.1.5 CarDisplay.sc

# i n c l u d e < s t d l i b . h># i n c l u d e <s t d i o . h># i n c l u d e ” e c s . sh ”# i n c l u d e ” sim . sh ”i m p o r t ” canBus / ne twork ” ;

b e h a v i o r CDMonitor (i n s i g n a l i n t F loorOut ,i n s i g n a l b i t [ 1 ] Up ,i n s i g n a l b i t [ 1 ] Down){

21


c h a r s t r i n g [BUFFER ] ;

w h i l e ( 1 ){w a i t F loorOut , Up , Down ;p r i n t f (”%d s e c \ t%l l u ps \ t \ t%s \ t F l o o r : %d , Up:%d Down:%d\n ” ,( i n t ) ( now ( ) / ( 1 SEC ) ) , now ( ) , a c t i v e p a t h ( s t r i n g , BUFFER−1) ,F loorOut , ( boo l ) Up , ( boo l )Down ) ;

}}

} ;

b e h a v i o r C a r D i s p l a y (i n c o n s t i n t ShaftNo ,ICanMacLink l i n k ,o u t s i g n a l i n t F loor ,o u t s i g n a l b i t [ 1 ] MovingUp ,o u t s i g n a l b i t [ 1 ] MovingDown ){

vo id main ( vo id ) {

s t r u c t ecsmsg msg ;

/∗ I n i t i a l i z a t i o n s : 1 s t F loor , s t a t i o n a r y ∗ /MovingUp = 0 ;MovingDown = 0 ;F l o o r = 1 ;

w h i l e ( 1 ){

/∗ Check incoming messages ∗ /l i n k . msgReceive (NONE, &msg , s i z e o f ( msg ) ) ;

s w i t c h ( msg . Type ){

c a s e ECSMSG CAR POSITION :

i f ( msg . S h a f t I D == Shaf tNo ){F l o o r = msg . F loo r ID ;

s w i t c h ( msg . m o v i n g d i r e c t i o n ){

22

c a s e UP :MovingUp = 1 ;MovingDown = 0 ;b r e a k ;

c a s e DOWN:MovingUp = 0 ;MovingDown = 1 ;b r e a k ;

c a s e NONE:MovingUp = 0 ;MovingDown = 0 ;b r e a k ;

}}b r e a k ;

d e f a u l t :b r e a k ;

}}

}} ;

/∗BFMb e h a v i o r C a r D i s p l a y U n i t (

i n c o n s t i n t s h a f t i d ,i n o u t s i g n a l r e s o l v e d b i t 4 [ 1 ] CAN DATA) {

∗ /

/∗TLM∗ /b e h a v i o r C a r D i s p l a y U n i t (

i n c o n s t i n t s h a f t i d ,I C a n P r o t c a n P r o t ){

/∗ Wires c o n n e c t e d t o m o n i t o r ∗ /s i g n a l i n t wi re1 ;s i g n a l b i t [ 1 ] wire2 , wi re3 ;

/∗ CanBus B e h a v i o r s ∗ // / (BFM) C a n P r o t o c o l T r c a n P r o t (CAN DATA, CAN CLK PERIOD ) ;CanMacLink canMacLink ( c a n P r o t ) ;

23

C a r D i s p l a y c a r d i s p l a y ( s h a f t i d , canMacLink , wire1 , wire2 , wi re3 ) ;CDMonitor c a r d i s p l a y m ( wire1 , wire2 , wi re3 ) ;


p a r {/ / BFM c a n P r o t ;

c a r d i s p l a y ;c a r d i s p l a y m ;

}}

} ;

/ / End of C a r D i s p l a y . s c

A.2 Test Bench and ResultsThe following is a simple test bench used to demonstrate how the ECS behaves with a floor panelrequest and a car panel request. A much detailed simulation was conducted, but the monitor outputis to large to include in this appendix.

A.2.1 TestBench.sc

# i n c l u d e < s t d l i b . h># i n c l u d e <s t d i o . h># i n c l u d e ” e c s . sh ”# i n c l u d e ” sim . sh ”i m p o r t ” canBus / ne twork ” ;

b e h a v i o r MessageSender ( ICanMacLink l i n k ) {

s t r u c t ecsmsg msg ;c o n s t c h a r t e s t b e n c h [ ] = ” T e s t Bench ” ;


/∗ F l o o r P a n e l Reques t from 5 t h f l o o r , u s e r wants go Down∗ /msg . Type= ECSMSG FLOOR REQUEST ;msg . S h a f t I D =4;msg . F loo r ID =5;msg . m o v i n g d i r e c t i o n = DOWN;w a i t f o r 5 SEC ; /∗ w a i t f o r sys tem t o i n i t i a l i z e ∗ /

24

l i n k . msgSend ( 1 2 9 , &msg , s i z e o f ( msg ) ) ;

/∗ Car P a n e l Reques t − User i n e l e v a t o r 2 wants t o go t o 5 t h f l o o r ∗ /msg . Type= ECSMSG CAR REQUEST ;msg . S h a f t I D =2;msg . F loo r ID =5;msg . f l a g = 1 ;w a i t f o r 15 SEC ;l i n k . msgSend ( 1 2 9 , &msg , s i z e o f ( msg ) ) ;

/∗ Qui t t h e s i m u l a t i o n ∗ /w a i t f o r 100 SEC ;p r i n t f (”%d s e c \ t%l l u ps \ t %23s \tDONE!\ n ” ,( i n t ) ( now ( ) / ( 1 SEC ) ) , now ( ) , t e s t b e n c h ) ;e x i t ( 1 ) ;

}} ;

/∗ BFM MODELb e h a v i o r Tes tBench ( i n o u t s i g n a l r e s o l v e d b i t 4 [ 1 ] CAN DATA) {∗ /

/∗TLM MODEL∗ /b e h a v i o r Tes tBench ( I C a n P r o t c a n P r o t ){

/ / C a n P r o t o c o l T r c a n P r o t (CAN DATA, CAN CLK PERIOD ) ; BFM Only

CanMacLink canMacLink ( c a n P r o t ) ;MessageSender msender ( canMacLink ) ;

/∗ main method of t h e PE ∗ /vo id main ( vo id ) {

p a r {/ / c a n P r o t ; BFM ONLY

msender ;}

}} ;

A.2.2 Simulation Log

25

0 s e c 0 psmain c o n t r o l l e r i n i t i a l i z e d

0 s e c 0 psT e s t Bench i n i t i a l i z e d

0 s e c 0 psT e s t Bench composing FLOOR REQUEST

0 s e c 0 psT e s t Bench msg composed : TYPE : 8 , F loo r ID : 5 , S h a f t I D : 4 , d i r e c t i o n : 1

5 s e c 5000297995232 psmain c o n t r o l l e r r e c e i v e d ECSMSG FLOOR REQUEST from F l o o r # 5

5 s e c 5000297995232 psT e s t Bench s e n t FLOOR REQUEST

5 s e c 5000297995232 psT e s t Bench composing CAR REQUEST

5 s e c 5000297995232 psT e s t Bench msg composed : TYPE : 0 , F loo r ID : 5 , S h a f t I D : 2 , d i r e c t i o n : 1

5 s e c 5000297995232 psMain . e l e v a t o r 1 . f u n i t 5 . f l r p a n e l . pane l m F l o o r P a n e l L i g h t up : 0 down : 1




5 s e c 5000598990416 psMain . e l e v a t o r 1 . m o t o r u n i t . motor GOING UP

5 s e c 5000598990416 psMain . e l e v a t o r 1 . m o t o r u n i t . motor C u r r e n t l y a t F l o o r : 1 go ing t o : 5

5 s e c 5000598990416 psMain . e l e v a t o r 1 . m o t o r u n i t . motor m ON and moving UP−0, DOWN−1 S t a t u s : 0

5 s e c 5000899985600 psmain c o n t r o l l e r r e c e i v e d CAR POSITION message : Motor 1 i s on f l o o r 1

5 s e c 5000899985600 psmain c o n t r o l l e r u p d a t e d t h e c a r l o c a t i o n f o r c a r 1 . I t i s now on f l o o r

15 s e c 5000899985600 ps

Main . e l e v a t o r 1 . s h a f t . c a r d i s p l a y . c a r d i s p l a y m F l o o r : 1 , Up : 1 Down : 05 s e c 5000899985600 ps

Main . e l e v a t o r 1 . f u n i t 1 . f l r d i s p l a y . f l o o r d i s p l a y m F l o o r : 1 , Up : 1 Down : 05 s e c 5000899985600 ps


26








Main . e l e v a t o r 1 . f u n i t 1 0 . f l r d i s p l a y . f l o o r d i s p l a y m F l o o r : 1 , Up : 1 Down : 015 s e c 15001197980832 ps

main c o n t r o l l e r r e c e i v e d CAR POSITION message : Motor 1 i s on f l o o r 215 s e c 15001197980832 ps

main c o n t r o l l e r u p d a t e d t h e c a r l o c a t i o n f o r c a r 1 . I t i s now on f l o o r215 s e c 15001197980832 ps











Main . e l e v a t o r 1 . f u n i t 1 0 . f l r d i s p l a y . f l o o r d i s p l a y m F l o o r : 2 , Up : 1 Down : 0

27

15 s e c 15001498976016 psmain c o n t r o l l e r r e c e i v e d ECS CAR REQUEST from Car 1 t o f l o o r

515 s e c 15001498976016 ps

main c o n t r o l l e r s e n d i n g CAR GO TO message t o S h a f t # 115 s e c 15001799971200 ps

Main . e l e v a t o r 1 . m o t o r u n i t . motor GOING UP15 s e c 15001799971200 ps

Main . e l e v a t o r 1 . m o t o r u n i t . motor C u r r e n t l y a t F l o o r : 2 go ing t o : 515 s e c 15001799971200 ps

Main . e l e v a t o r 1 . m o t o r u n i t . motor m ON and moving UP−0, DOWN−1 S t a t u s : 015 s e c 15002100966384 ps














main c o n t r o l l e r r e c e i v e d ECS CAR REQUEST from Car 2 t o f l o o r520 s e c 20000595990464 ps

28


T e s t Bench s e n t CAR REQUEST20 s e c 20000595990464 ps

T e s t Bench Q u i t i n g i n 100 s e c o n d s20 s e c 20000896985648 ps






main . e l e v a t o r 2 . s h a f t . c a r d i s p l a y . c a r d i s p l a y m F l o o r : 1 , Up : 1 Down : 020 s e c 20001197980832 ps












29




















Main . e l e v a t o r 1 . s h a f t . c a r d i s p l a y . c a r d i s p l a y m F l o o r : 3 , Up : 1 Down : 0

30

25 s e c 25003301947168 psMain . e l e v a t o r 1 . f u n i t 1 . f l r d i s p l a y . f l o o r d i s p l a y m F l o o r : 3 , Up : 1 Down : 0









25 s e c 25003301947168 psMain . e l e v a t o r 1 . f u n i t 1 0 . f l r d i s p l a y . f l o o r d i s p l a y m F l o o r : 3 , Up : 1 Down : 0

30 s e c 30001495976064 psmain c o n t r o l l e r r e c e i v e d CAR POSITION message : Motor 2 i s on f l o o r 2

30 s e c 30001495976064 psmain c o n t r o l l e r u p d a t e d t h e c a r l o c a t i o n f o r c a r 2 . I t i s now on f l o o r

230 s e c 30001495976064 ps









31





















32





















33





















34





















35



















Main . e l e v a t o r 1 . m o t o r u n i t . motor s e n d i n g CAR POSITION45 s e c 45005402913552 ps

Main . e l e v a t o r 1 . m o t o r u n i t . motor m OFF45 s e c 45005703908736 ps

36



Main . e l e v a t o r 1 . m o t o r u n i t . motor s e n d i n g OPEN DOORS45 s e c 45005703908736 ps












Main . e l e v a t o r 1 . m o t o r u n i t . motor w a i t i n g f o r 10 s e c t o c l o s e45 s e c 45006004903920 ps

Main . e l e v a t o r 1 . s h a f t . c a r d o o r . cdoor m Car Door i s : 145 s e c 45006004903920 ps

Main . e l e v a t o r 1 . f u n i t 5 . f l r d o o r . fdoor m F l o o r Door i s : 150 s e c 50003897937632 ps




37





















38









Main . e l e v a t o r 1 . m o t o r u n i t . motor s e n d i n g CLOSE DOORS55 s e c 55006302899152 ps

Main . e l e v a t o r 1 . s h a f t . c a r d o o r . cdoor m Car Door i s : 055 s e c 55006302899152 ps

Main . e l e v a t o r 1 . f u n i t 5 . f l r d o o r . fdoor m F l o o r Door i s : 055 s e c 55006603894336 ps

main c o n t r o l l e r r e c e i v e d ECS CAR ARRIVED message from S h a f t # 155 s e c 55006904889520 ps

main c o n t r o l l e r s e n t FLOOR REQUEST GRANTED message t o f l o o r # 555 s e c 55006904889520 ps

Main . e l e v a t o r 1 . f u n i t 5 . f l r p a n e l . pane l m F l o o r P a n e l L i g h t up : 0 down : 055 s e c 55006904889520 ps







Main . e l e v a t o r 2 . f u n i t 1 . f l r d i s p l a y . f l o o r d i s p l a y m F l o o r : 5 , Up : 1 Down : 0

39










60 s e c 60005399913600 psmain c o n t r o l l e r r e c e i v e d ECS CAR REQUEST from Car 2 t o f l o o r

560 s e c 60005399913600 ps


Main . e l e v a t o r 2 . m o t o r u n i t . motor s e n d i n g CAR POSITION60 s e c 60005700908784 ps

Main . e l e v a t o r 2 . m o t o r u n i t . motor m OFF60 s e c 60006001903968 ps



Main . e l e v a t o r 2 . m o t o r u n i t . motor s e n d i n g OPEN DOORS60 s e c 60006001903968 ps




Main . e l e v a t o r 2 . f u n i t 3 . f l r d i s p l a y . f l o o r d i s p l a y m F l o o r : 5 , Up : 0 Down : 0

40








60 s e c 60006302899152 psMain . e l e v a t o r 2 . m o t o r u n i t . motor w a i t i n g f o r 10 s e c t o c l o s e

60 s e c 60006302899152 psMain . e l e v a t o r 2 . s h a f t . c a r d o o r . cdoor m Car Door i s : 1

60 s e c 60006302899152 psMain . e l e v a t o r 2 . f u n i t 5 . f l r d o o r . fdoor m F l o o r Door i s : 1

70 s e c 70006302899152 psMain . e l e v a t o r 2 . m o t o r u n i t . motor s e n d i n g CLOSE DOORS

70 s e c 70006600894384 psMain . e l e v a t o r 2 . s h a f t . c a r d o o r . cdoor m Car Door i s : 0

70 s e c 70006600894384 psMain . e l e v a t o r 2 . f u n i t 5 . f l r d o o r . fdoor m F l o o r Door i s : 0

70 s e c 70006901889568 psmain c o n t r o l l e r r e c e i v e d ECS CAR ARRIVED message from S h a f t # 2

70 s e c 70006901889568 psmain c o n t r o l l e r s e n t CAR REQUEST GRANTED message t o E l e v a t o r # 2

70 s e c 70007202884752 psMain . e l e v a t o r 2 . s h a f t . c a r p a n e l . pane l m C a r P a n e l B u t t o n #1 i s 0






41





120 s e c 120000595990464 psT e s t Bench DONE!

42

system-level modeling and simulationof an elevator...

Documents