The goal of this Dezyne modelling example is to create a control component and related interface models for an electric “up and over” automatic garage door. The exercise focuses primarily on modelling the control logic of the door. I have provided two versions of the example models. The first is a fully verified, working set of design models. The second is a set of models which include some of the original errors that I made when building the models. One quick way to learn about Dezyne would be to play with the buggy version of the models and see if you can figure out the various problems. Otherwise see if you can create your own design to fulfil the requirements below.
There are a number of hardware parts to the door, as described below, some of which are shown in the photo below.
A motor for opening and closing the door.
The motor can be told to:
* Set direction open
* Set direction close
In addition the motor can report:
‘PowerWarning’ when it’s having to work too hard to open the door.
‘DriveFailure’ if the motor stalls or hits a hard problem. If the motor stalls, it will automatically stop itself.
An overhead track, driven by the motor that ‘screws’ the door open or closed. The track has limit switches that indicate when the door is either opened or closed. If the track indicates neither then position of the door is unknown.
The track can report:
* Limit switch = Door open
* Limit switch = Door closed
* Limit switch = !Open and !Closed = Position unknown
* Door proximity warning. When the door is closing this means that the door is obstructed by something.
A simple wall switch – press to toggle
Door Controller Operation
The door operates as follows:
When the wall switch is pressed:
If the door is open then it should be closed
If the door is closed then it should be opened
If the position of the door is unknown then it should be opened
If the door is OPENING, then it should be closed.
If the door is CLOSING, then it should be opened
If the door is OPENING or CLOSING and the switch is pressed twice quickly, it should be stopped
If the motor is struggling to open the door (powerWarning), this should be flagged e.g. so that a led could be turned on. Normal operation can continue.
If the motor stalls (driveFailure) the motor should immediately be stopped and the system must be reset. No other actions allowed.
If the door encounters an obstruction then it should open.
Your challenge, should you choose to accept it, is to model a solution to the problem.
For illustrative purposes I have chosen to implement the following solution to this problem. I have put all the control logic into a single component, whereas one could well argue that it would be best to have some of the logic in the required components. I have designed my solution this way as it makes demonstrating certain features of Dezyne easier. Feel free to implement your own solution any way you wish.
I imagine that this software will run on a SoC or other small footprint system and therefore I have chosen to implement my design according to the architecture diagram shown below. I have assumed that all the bottom level components will be simple handwritten components that will deal directly with hardware, controller ports and interrupts. For example the WallSwitch will perhaps be an interrupt subroutine, triggered when the physical wall switch is pressed. The Motor Control component will read and write the registers of the motor control hardware, The LimitSwitch component will be triggered perhaps by interrupt when one of the two physical limit switches is pressed. The Timer will interface to a hardware timer.
The top level interface to the controller has the following behaviour:
When the hardware is powered up, the controller will be NotReady. The main() routine will firstly initialise the controller, which will then enter the Ready state. It will only exit the Ready state if there is an error, in which case it will do nothing until the systems has been reset. If there is a ‘warning’ event, it might well light a led on the outside of the door control unit.
The limit switch interface has the following behaviour:
The motor only accepts initialisation and set direction commands when it’s in the Off state. It’s unclear from the specification whether the motor needs initialising, but I’ve built in the possibility anyway.
When the motor is on, a power warning leaves it in the same state, a drive fault returns it to the off state - and stops the motor.
The limit switch interface has the behaviour shown in the diagram below. Again I have provided the possibility to initialise this component. This would probably involve determining if the door is in a known position. After initialisation the limit switch component is idle. Once the door is transitioning the component looks for the appropriate limit switch or proximity event and acts accordingly.
The essential behaviour of the door control component is shown below. However it will be easier to understand the behaviour of the controller by following a sequence trace.
Door Control Initialisation and First Switch Press
The following sequence trace shows the ‘happy flow’ behaviour of the door controller. The sequence starts with the initialisation of the GarageDoorControl, limitSw and motorControl components. Next, the wall switch is pressed. The controller then queries the position of the door, which is currently unknown. It then sets the motorControl to open the door and starts the motor. The limit switch is then informed that the door is opening. The sequence ends with the limit switch reporting that the door has reached the closed position and the door controller stopping the motor. It also cancels a timer, which in this sequence was not used.
For the remaining behaviour of the door controller, I suggest that you download the online example that we have provided. You can do this in Dezyne by choosing “ File / New / Dezyne Example Project, then select the “GarageDoorControl” example. Start by simulating the behaviour of the doorControl component and work your way through the various use cases. For a more interesting challenge you could download the “GarageDoorControlErr” version of the example and try to solve the various errors that arise as a result of verifying it.
Note that all of the diagrams included in this document have been produced in and exported from Dezyne. The System View and State Charts are part of the Dezyne editor. The Sequence Trace has been produced using the Dezyne simulation engine.
If you have questions that weren’t by this Guide,
let our support team help you out.