Logic Control Summer Semester Assignment: Modeling and Logic Controller Design 1

Transcription

1 TECHNISCHE UNIVERSITÄT DORTMUND Faculty of Bio- and Chemical Engineering Process Dynamics and Operations Group Prof. Dr.-Ing. Sebastian Engell D Y N Logic Control Summer Semester 2018 Assignment: Modeling and Logic Controller Design 1 Please solve the following tasks and hand in the solution either as PDF on Moodle course web-page or in paper form before July 18, 2018, 13:59 The codesys files should be also sent to the above mentioned web-page before the deadline. No points will be given for beauty, but points will be subtracted if the solution is incomprehensible. Furthermore, you are required to prepare the solution by yourself, not in teams. If we find that several students submit the same (or a very similar) solution, we will divide the points of the solution among all students who have copied (including the original version). In addition, please note: You can at most achieve 100 points that are distributed between the tasks as indicated below. You do not have to prepare your solution on a computer using word processing or image software! It is completely sufficient to pass in a hand-written solution if it is clear and comprehensible. Experience shows that e.g. drawing an automaton model on a computer takes a lot of time that is spent unnecessarily since it will not be rewarded by us. Task 1: 1.1 Background Logic Controller Design for an Airport Baggage Handling System (40 Points) A baggage handling system (BHS) is a type of conveyor system installed in airports that transports checked luggage from ticket counters to areas from where the bags can be transported to airplanes for loading. A BHS also transports checked baggage coming from airplanes to baggage claims or to an area from where the baggage can be transported to other airplanes for loading. 1 If you have any questions regarding the tasks, please post it on Moodle. (A separate forum will be created solely for the assignment purpose)

2 Accept Reject 1.2 Description of the Plant Figure 1: Airport baggage handling system. Fig. 1 shows a scaled down version of an airport baggage handling system. It contains three conveyor belts, an X-ray machine and a diverter. A baggage is placed in the conveyor belt CB1 by the operator at the check-in terminal and it is transported to the diverter through CB2, X-ray and CB3. All the conveyor belts are assumed to be running at a constant velocity. The optical sensors (S1) (S4) at the conveyor belts sense the baggage in front of them. There can be only one baggage in the X-ray machine when it scans. The X-ray machine sends two signals to the controller either to accept the baggage that it scans or to reject it. The diverter at the end is used to separate the accepted and the rejected baggage. The diverter must be in the down position for the rejected baggage and must be in the up position for the accepted baggage. Similar to the X-ray machine, there can be only one baggage at the diverter at any given time. The diverter takes the baggage to the corresponding location. Table 1 shows the input variables to the controller from the sensors, and table 2 shows the output variables from the controller to the subsystems. Table 1: Inputs to the controller. Input Type Description S1, S2, S3, S4 Boolean Baggage identified at the position of the sensors Accept Boolean True: if True for more than one second, accept the bag being scanned in the X-ray machine Accept Boolean False: Reject the bag being scanned in the X-ray machine Emergency stop Boolean False: Emergency, Stop the whole process... continued 2

3 Continuation Input name DescriptionDuration of action Emergency stop Boolean True: Normal condition Diverter pos Boolean True: Diverter is in the up position Diverter pos Boolean False: Diverter is in the down position Table 2: Outputs from the controller. Output Type Description CBx run Boolean True: Run the CBx conveyor (x=1,2,3). CBx run Boolean False: Stop the CBx conveyor (x=1,2,3). Xray run Boolean True: Run the X-ray. Xray run Boolean False: Stop the X-ray. Diverter cmd Boolean True: move the diverter upwards. Diverter cmd Boolean False: move the diverter downwards Assumptions and Terminology Each of the position optical sensors S1, S2, S3, S4 changes its state from False to True when an object passes in front of it. E.g., in order to detect that an object arrives at the sensor S1 you need to detect the rising edge of the signal produced by the sensor. A baggage is assumed to leave a conveyor if a falling edge is detected at the optical sensors placed at the end of the corresponding conveyor. Initially the baggage handling system is assumed to be empty. A baggage enters the X-ray if it leaves S2 and leaves the X-ray if it leaves S3. A baggage takes minimum of three seconds to cross the X-ray. The default value of X-ray signal Accept is False and it changes the value to True for a minimum of one second before the baggage leaves the X-ray, if the baggage is accepted (else it remains False). When the baggage leaves the X-ray, the Accept signal is automatically reset to False. The conveyors and the X-ray machine require two seconds to run from the time CBx run and Xray run command are given and are assumed to stop immediately when CBx run and Xray run are set to False for all x=1,2, Interlocks The following interlocks must be met at all times during the operation of the baggage handling system. For safety reasons, there can be only up to two baggages in X-ray and CB3 together. There must be a maximum of only one baggage in X-ray machine at any given time. 3

4 The diverter can only handle only one bag at a time and takes three seconds to process a given bag. The diverter must be in upwards position for the accepted baggage and must be in downwards position for the rejected baggage. A particular conveyor can start only when the succeeding conveyor is running. For example, CB1 can start only when CB2 runs. Similarly the precondition for X-ray to start is that CB3 is running. If a conveyor stops, all the preceding conveyors must be stopped. For example, CB1 must stop when CB2 stops. Similarly when CB3 stops, X-ray, CB2 and CB1 must be stopped. When emergency stop is pressed, the whole process needs to be stopped immediately (all outputs set to False). 1.5 Process steps In the following, the process steps required to run the baggage handling system is given. Note the correct implementation of a PLC software project. The control goals must be implemented in parallel with, and taking into account, the interlocks. When a baggage is identified at the sensor S1, start all the CBs and the X-ray sequentially such that the interlocks are met. Take note of the time necessary for the conveyors to run. When there is no baggage in the X-ray, the conveyor CB2 can pass the baggage to the X-ray. Otherwise CB2 must be stopped until the X-ray becomes empty if a baggage is identified at S2. If CB2 stops, CB1 must also be stopped because of the interlock. If the X-ray becomes empty, the conveyors CB2 and CB1 must be started again in the required sequence. When the X-ray gives accept or reject feedback, the result must be stored and the corresponding baggage must be diverted accordingly when it reaches the diverter. If a previous baggage is being processed by the diverter, the position of the diverter must not be switched. If the diverter is processing a baggage and a new baggage is identified at S4, the conveyor CB3 must be stopped for the diverter to finish processing. If CB3 stops, the X-ray, CB2 and CB1 must also be stopped. If the diverter position does not correspond to the expected position when a baggage is identified at S4, the conveyor CB3 must be stopped and the diverter position must be set to the required position. Once the position of the diverter matches the expected position (that corresponds to the X-ray decision when the baggage was inside the X-ray), the baggage can be passed on to the diverter by starting CB3, X-ray, CB2 and CB1 in the required sequence. The whole system must be stopped when S1 is not active for 5 minutes and there is no baggage in the system. emergency stop also stops the whole system even if a baggage is identified at S1. 4

5 1.6 Alarms Alarms are generated to alert the operator in the case of any malfunction in the system. If the diverter does not change the position within 5 seconds from the moment the command has been issued, the controller initiates an alarm indicating the malfunction of the diverter by setting the variable (Alarm 1) to True. If the X-ray machine rejects 10 bags in a row or if the Accept signal becomes True when there is no baggage in the X-ray, the X-ray is assumed to malfunction and this is notified by setting the variable (Alarm 2) to True. If any given optical sensor is True for more than 5 seconds continuously, sensor malfunction (blockage) is reported by setting (Alarm 3) to True. Table 3: Alarms initiated by the controller. Output Type Description Alarm 1 Boolean Diverter Malfunction Alarm 2 Boolean X-ray Malfunction Alarm 3 Boolean Sensor malfunction. Tasks: 1. Using FBDs (Functional Block Diagrams), implement a logic controller that realizes the given process specifications and incorporates the required interlocks. (32 points) 2. Implement the alarms using Instruction List (IL). (8 points) Important Notes:- 1- Use CodeSys to produce the logic required in a systematic way. 2- The Correct implementation of the control goals and interlocks will be graded based on simulation runs on different possible scenarios. Incorrect code cannot receive full marks, but will be graded based on the written implementation. 3- If you introduce additional internal variables, declare them formally (name, type and initial value (if needed)). It is advised also to add a comment beside each new variable explaining its usage. As a hint, Bag in xray, Bag in diverter variables can be used to indicate the presence of bags in the corresponding places. 5

6 Task 2: A Timed Model of a Controlled Airport (60 Points) The goal of this task is to create a timed model of a (strongly simplified) small, controlled airport, consisting of several synchronizing timed and finite-state automata. 2.1 Description of the Controlled Airport Fig. 2 shows a conceptual, simplified outline of a small, controlled airport. The airport consists of: Figure 2: Simplified illustration of a small, controlled airport. A single runway: The runway is headed directly due east, and airplanes approach the runway for landing from the west, while they depart after starting to the east. Note that in reality, the landing/starting direction depends on the current wind direction, since airplanes usually land against the wind. For simplicity reasons, in this task planes always land/start from west to east. A single parking area: The airport considered here only offers a single generalaviation (GA) parking area that offers two parking slots for planes. A single taxiway: Planes use the taxiway to reach the parking area after landing and to reach the runway from the parking area before departure. Since planes always 6

7 use the runway from west to east, they leave the runway at the east end after landing and enter the runway at the west before departure. The airfield traffic pattern (ATP): The planes arriving at the airport must follow a airfield traffic pattern that leads them to the runway for landing on a counter-clockwise path. Once a plane has entered this pattern, it will follow it until it lands (unless asked by the ATC to leave the pattern, see below). The ATP consists of the following sections/legs 2 : Upwind leg: This leg is used by departing planes, and by planes that had to cancel their landing (also known as go-around). Note that this leg is ignored in this task, i.e. planes move from final approach directly to the crosswind leg. Crosswind leg: In this example, planes that arrive from the south or from the east enter the traffic pattern in this leg. Downwind leg: In this example, planes that arrive from the north enter the traffic pattern in this leg. Base leg: In this example, planes that arrive from the west enter the traffic pattern in this leg. Final approach: The last stage of the landing procedure. Planes on final approach are aligned with the runway and will land (or go around, see below) directly after leaving this leg. An air traffic control (ATC) center: All traffic at, around, and above the airport is coordinated by an air traffic control (ATC) center that can communicate with the planes at all times via radio signals. This is where the name controlled airport derives from (airports without ATCs are called uncontrolled airports). Note that the ATC has been simplified significantly. E.g. you only need to consider a single ATC (usually there are several), and its only task is to ensure the adherence to the airfield traffic pattern. Your task is to model the airport, the planes, and the ATC in separate, synchronizing automata. Fig. 3 outlines the structure and the communication elements of the model. All models except for the ATC automaton must be implemented as timed automata (TA) - the ATC automaton must be a finite-state automaton (FSA). The overall model contains several instances of the plane model. You are only required to design the template for this instantiation. Most communication is done using synchronization labels, with the exception that the model of the airport uses uni-directional communication with the ATC model via the outputs of the latter. The synchronization labels are introduced in table 4. Note that, for simplicity, the upwind leg is ignored, i.e. planes leaving the final approach section (after a go-around) directly enter the crosswind leg. 2.2 General Modeling Principles In the following, several modeling principles are given that you must adhere to when creating the models. 2 Note that many of the names of these sections derive from the fact that the wind usually blows in the opposite direction of the landing/starting planes. 7

8 Airport (A AP ) TA outputs of A AP ATC (A ATC ) FSA Landed Plane (A P ) Instance 1 TA Plane (A P ) Instance 2 TA Plane (A P ) Instance 3 TA Plane (A P ) Instance n TA CL, DL, BL, CL_P, DL_P, BL_P, FA_P, Leave_P Figure 3: Structure of the airport model. Table 4: Synchronization labels. Label Landed CL DL BL CL P DL P BL P F A P Leave P Description A plane on final approach lands on the runway A plane (waiting south or east) enters the ATP in the crosswind leg A plane (waiting north) enters the ATP in the downwind leg A plane (waiting west) enters the ATP in the base leg A plane (already in the ATP) moves from the upwind leg/final approach to the crosswind leg A plane (already in the ATP) moves from the crosswind to the downwind leg A plane (already in the ATP) moves from the downwind to the base leg A plane (already in the ATP) moves from the base leg to final approach Used by ATC to order a plane to leave the ATP (used if the ATP is full) 1. All automata models created here must implement the Moore syntax, i.e. the states uniquely determine the outputs (g : X Y ). Fig. 4 depicts how the states of the three automata should look like in your drawings. Figure 4: States of the automaton models. In order not to clutter up the sketches of the automata models, the states and outputs must be named according to z P and y P (for plane), z AP and y AP (for airport), and z ATC and y ATC (for ATC ), followed by a number. During modeling, please number the states of the models consecutively according to z,1,..., z,n and y,1,..., y,n, with n being the number of states of the model. To each model, please 8

9 provide a table that describes the meaning of each state. In case of TA, declare invariants within the state (see Fig. 4). An example for the plane automaton is given below. 2. The semantics of synchronization is strict synchronization. This means that a synchronizing transition in any automaton can only be taken if all automata can synchronize. However, as described in the lecture, you may leave out any self loops that are only needed to implement strict synchronization, but that are not necessary to implement the specification. As an example, the plane automaton requires the Landed synchronization label only once. Strictly speaking, you would have to add self-loops to all of the other states. However, in some cases, it is actually wrong to assign self-loops to be able to process all synchronization labels. As an example, the ATC automaton, which controls the planes in the ATP, must not have self-loops for all labels, since a plane can only take an action with respect to the ATP if the ATC automaton can synchronize and, at the same time, change to another state. As a simplification, assume that self-loops are placed on those states for which it actually makes sense, and that this is NOT your task. 3. The outputs of the automaton models are persistent, i.e. they are active as long as the automaton is in the corresponding state. 4. All synchronizing (!) transitions (i.e. transitions that synchronize on a label) are urgent, i.e. are taken as soon as possible. This does not include spontaneous transitions and non-synchronizing transitions, which are considered non-urgent. 5. When modeling the components, please use a complete Din-A4 page for every model and assign the space between the states generously. 6. You do not have to connect all transitions to their target nodes if this drastically reduces the clarity of the automaton model. If necessary, just draw an outgoing transition from the source node and assign the name of the target node to its end (e.g. z P,1 ). 7. If you have to assign a very long Boolean expression as a condition to a transition, just define an auxiliary condition (e.g. y aux = y P,5 y AP,7 y AT C,9 ) and assign it to the transition. 2.3 The Plane Automaton The plane automaton is instantiated n times within the complete model, as described above. Each plane automaton instance models one plane in the airspace of the airport, from entering the airspace to landing. Your task is to develop the template automaton. The plane automaton must be designed according to the following specification: Initially, the automaton is not assigned to any plane. When a plane enters the airspace of the airport, it enters a waiting pattern (see figure above), and the plane automaton goes to a state that represents in which direction 9

10 (south, east, north, west) the plane is waiting. This should be a spontaneous event (i.e. the automaton can move from the initial state to one of the waiting states spontaneously, without input from other automata). If a plane is in any of the waiting states, it can enter the ATP (the crosswind leg from south and east, the downwind leg from north, and the base leg from the west) at the earliest 200 seconds after it arrived in the waiting position, if the ATC automaton indicates (by allowing synchronization on the corresponding label CL, DL, or BL) that the leg is free (see ATC specification below). If the plane automaton was not able to synchronize with the ATC automaton 250 seconds after it entered the waiting state, it enters a waiting loop (see figure above). Once it has entered this loop, it again takes at least 200 seconds until it can enter the ATP, and 250 seconds until it enters the loop again. This loop can be taken arbitrarily many times, until the plane is able to enter the ATP. After a plane has entered the crosswind leg, it takes at least 100 seconds until it enters the downwind leg (synchronization on DL P ). Note that the is no upper time limit, as it is assumed that the ATC can control the speed of the plane once it has entered the ATP) - this is however not modeled. After a plane has entered the downwind leg, it takes at least 300 seconds until it enters the base leg (synchronization on BL P ). Note that the is no upper time limit, as it is assumed that the ATC can control the speed of the plane once it has entered the ATP) - this is however not modeled. After a plane has entered the base leg, it takes at least 100 seconds until it enters the final approach (synchronization on F A P ). Note that the is no upper time limit, as it is assumed that the ATC can control the speed of the plane once it has entered the ATP) - this is however not modeled. Once the plane is on final approach, it will land after at least 100 seconds if the runway and the taxiway are free (i.e. if the airport and ATC automata can synchronize on the label Landed). The plane automaton will then go back into its initial state. If the runway and the taxiway are not free (i.e. synchronization on Landed is not possible), the ATC can directly instruct the plane to leave the ATP (by synchronizing on Leave P ). If neither of these options is feasible after 50 more seconds, the plane will go around and enter the crosswind leg again (synchronizing on CL P ). Tab. 5 shows a description of all the necessary states (and the corresponding output symbols) of the plane model, and Fig. 5 provides a template for the automaton. Subtask (a): (20 points) Create the TA model of the plane automaton, based on the template (by adding transitions, invariants, transition conditions, and synchronization labels) and under consideration of the modeling principles given in section 2.2. Clearly define each clock that you are using. 10

11 Table 5: States and outputs of the plane automaton. State/Output Description z P,0 /y P,0 The automaton is not assigned to a plane. z P,1 /y P,1 The plane is waiting south. z P,2 /y P,2 The plane is waiting east. z P,3 /y P,3 The plane is waiting north. z P,4 /y P,4 The plane is waiting west. z P,5 /y P,5 The plane is in the crosswind leg. z P,6 /y P,6 The plane is in the downwind leg. z P,7 /y P,7 The plane is in the base leg. z P,8 /y P,8 The plane is on final approach. 11

12 Figure 5: Template for subtask (a). 12

13 2.4 The Airport Automaton The airport automaton models all the facilities of the airport, i.e. the runway, the taxiway, and the GA parking area. For the runway, three states must be distinguished (f ree/plane landed/plane starting). For the taxiway, three states must be distinguished (f ree/plane on way to runway/plane on way to parking), and for the parking area, three states must be distinguished (representing the number of parked planes). The following list presents specifications and assumptions that must be adhered to during modeling: Initially, the runway and the taxiway are idle (i.e. unoccupied by planes), and the parking area is empty. After a plane has landed (synchronization on Landed), the runway becomes busy. Between 60 and 180 seconds after landing, the plane leaves the runway and enters the taxiway. Between 120 and 240 seconds after the plane has entered the taxiway, it enters the parking area and parks. If the parking area is not empty and both, the runway and the taxiway are idle, a plane from the parking area can leave the parking area for the taxiway to depart. This must be modeled with a spontaneous transition. Once a departing plane as entered the taxiway, it takes between 60 and 120 seconds to reach and enter the runway. Once a departing plane as entered the runway, it takes between 80 and 140 seconds for departure. Note that departing planes just disappear from the model after departure, i.e. they are not modeled using a plane automaton instance. If a plane lands (synchronization on Landed) while either the runway or the taxiway are not idle, the airport automaton must go into an error state. If the parking area is full (max. capacity: 2 planes) and another plane lands (synchronization on Landed), the automaton must go into an error state. Subtask (b): (20 points) Create a TA model of the airport according to the above specifications under consideration of the modeling principles given in section 2.2. To this end, first define the complete set of states that is necessary to model the system (but not more). Additionally, define a set of clocks to model the time dynamics of the system. 13

14 2.5 The ATC Automaton: Specifications and Assumptions The ATC automaton models the control and monitoring actions of the ATC. In each of the four considered legs of the ATP, at most one plane may be at any time. Thus, the ATC automaton must distinguish the states of the four legs of the ATC (crosswind leg, downwind leg, base leg, final approach) as either busy (1) or free (0). Note: Assume that the airfield traffic pattern can hold at most 2 planes at the same time. The following list presents specifications and assumptions that must be adhered to during modeling: Initially, all four legs of the ATP are unoccupied (0). If a plane can enter any of the three legs crosswind, downwind, or base (i.e. a plane is waiting at the corresponding position and the leg is unoccupied), the automaton must allow this by synchronizing with the corresponding plane automaton and must change into a state that reflects that the corresponding leg is occupied. If a plane within the ATP moves from one leg to the next, the automaton must reflect this moving by changing to the corresponding state. If a plane is on final approach and both the runway and the taxiway of the airport are empty (outputs of the airport automaton), the ATC automaton tells the plane to land (synchronization on Landed). If a plane is on final approach and either the runway or the taxiway of the airport are occupied (outputs of the airport automaton), the ATC automaton tells the plane to go around (synchronization on CL P ). If a plane is on final approach and it (a) cannot land and (b) the crosswind leg is occupied (outputs of the airport automaton), the ATC automaton must tell the plane to leave the ATP (label Leave P ). Assume that when a plane leaves the ATP, it will enter a waiting position until it can enter again. Subtask (c): (20 points) Create a FSA model of the ATC according to the above specifications under consideration of the modeling principles given in section 2.2. To this end, first define the complete set of states that is necessary to model the system (but not more). 14