Layered Queueing Network Modeling of Security Systems

Layered Queueing Network Modeling of Security Systems
Slide Note
Embed
Share

This content discusses the modeling of software systems focusing on security aspects such as CCTV storage, door access control, and building security systems using Layered Queueing Network (LQN) examples. It covers various components and subsystems involved, along with scenarios related to door access control and CCTV capture.

  • Security Systems
  • Modeling
  • Layered Queueing Network
  • Software
  • CCTV

Uploaded on Feb 25, 2025 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. 1 Layered Queueing Network Modeling of Software Systems Building Security System (buffering) Murray Woodside 5201 Canal Building

  2. Building Security System SYSC4102/5101 LQN-examples slide 2 Two subsystems: CCTV storage, and door access control hope to manage up to 100 cameras Components, shown as UML with MARTE annotations: <<PAresource>> DoorLock Actuator <<PAresource>> SecurityCard Reader <<PAresource>> Video Camera <<PAresource>> Disk {PAcapacity=2} <<PAresource>> LAN <<PAhost>> ApplicCPU VideoAcquisition Video Controller <<PAhost>> DB_CPU <<PAresource>> Buffer {PAcapacity=$Nbuf} AccessControl Database Acces Controller AcquireProc Buffer Manager StoreProc

  3. Door Access Scenario SYSC4102/5101 LQN-examples slide 3 <<PAopenLoad>> 1. Poisson arrivals of Users 2/s {PAoccurencePattern = ( poisson , 0.5, s ), PArespTime =(( req , percentile ,95, (1, s )), ( pred , percentile , 95, $UserR)) } <<PAcontext>> <<PAresource>> Alarm <<PAresource>> Disk {PAcapacity=2} <<PAresource>> CardReader <<PAresource>> DoorLock <<PAresource>> Database {PAcapacity=10} <<PAresource>> Access Controller User o <<PAstep>> {PAextOp=(read, 1)} <<PAstep>> {PAdemand=( asmd , mean , (1.8, ms ))} <<PAstep>> readCard {PAdemand=( asmd , mean , (1.8, ms ))} admit (cardInfo) getRights() User puts card thru reader <<PAstep>> {PAdemand=( asmd , mean , (1.5, ms )), PAprob = 0.4} readRights() o [not_in_cache] readData() <<PAstep>> {PAdemand=( asmd , mean , (1.8, ms ))} 2. Process card, check rights <<PAstep>> {PAdemand=( asmd , mean , (0.3, ms ))} <<PAstep>> {PAdelay=( asmd , mean , (500, ms )), PAprob = 1} checkRights() [OK] openDoor() enterBuilding <<PAstep>> {PAdemand=( asmd , mean , (0.2, ms ), PAprob=0.2} <<PAstep>> {PAprob = 0} [need to log?] logEvent() 3. Open door or record alarm [not OK] alarm() <<PAstep>> {PAdemand=( asmd , mean , (3, ms ))} writeEvent() o <<PAstep>> {PAdemand=( asmd , mean , (1.8, ms ))} writeRec() Requirement: 1 s response with 95% probability 4. Write log of events

  4. CCTV capture scenario SYSC4102/5101 LQN-examples slide 4 <<PAcontext>> <<PAresource>> Video Controller <<PAresource>> BufferManager <<PAresource>> AcquireProc <<PAresource>> StoreProc <<PAresource>> Database {PAcapacity=10} o 1.Trigger camera read events (the N cameras were not modeled) This object manages the resource Buffer <<PAstep>> <<PAstep>> {PArep = $N} Buffer operations: get release {PAdemand =( asmd , mean , (1.5, ms )} *[$N] procOneImage(i) getBuffer() o <<GRMacquire>> allocBuf (b) <<PAstep>> {PAdemand=( asmd , mean , (0.5, ms ))} <<PAclosedLoad>> {PApopulation = 1, PAinterval =(( req , percentile ,95, (1, s )), ( pred , percentile , 95, $Cycle)) } o <<PAstep>> {PAdemand=( asmd , mean , ($P * 1.5, ms )), PAextOp = (network, $P)} 2. Put the image in a buffer, send to database o getImage (i, b) <<PAstep>> <<PAstep>> {PAdemand=( asmd , mean , (0.9, ms ))} {PAdemand=( asmd , mean , (1.8, ms))} <<PAstep>> {PAdemand=( asmd , mean , (1.1, ms ))} <<PAstep>> {PAdemand=( asmd , mean , (2, ms ))} passImage (i, b) 3. Store image in database storeImage (i, b) store (i, b) <<PAstep>> {PAdemand=( asmd , mean , ($B * 0.9, ms )),, PAextOp=(writeBlock, $B)} <<PAstep>> {PAdemand=( asmd , mean , (0.2, ms ))} writeImg (i, b) freeBuf (b) <<GRMrelease>> releaseBuf (b) <<PAstep>> {PAdemand=( asmd , mean , (0.5, ms ))} o

  5. The LQN Model SYSC4102/5101 LQN-examples slide 5 Video Capture subsystem Door Access subsystem Shared Resources acquireLoop [1.8] User VideoController rate=0.5/secUsers UserP (1) ($N) procOneImage [1.5,0] readCard [1, 0] (1,0) CardReader AcquireProc Applic CPU CardP (1,0) admit [3.9, 0.2] AccessController alloc [0.5, 0] BufferManager (0, 0) (forwarded) alarm [0,0] Alarm bufEntry Buffer Dummy (1, 0) (1, 0) (1, 0) (forwarded) AlarmP (0, 1) (0, 0.2) getImage [12,0] passImage [0.9, 0] storeImage [3.3, 0] lock [0, 500] AcquireProc2 StoreProc Lock ($P, 0) LockP (1, 0) (1, 0) readRights [1.8,0] network [0, 1] releaseBuf [0.5, 0] writeImg [7.2, 0] writeEvent [1.8, 0] Network (infinite) BufMgr2 DataBase (10 threads) (0.4, 0) (1, 0) ($B, 0) DB CPU NetP Disk (2 threads) readData [1.5, 0] writeRec [3, 0] writeBlock [1, 0] DiskP

  6. Handling of Buffering SYSC4102/5101 LQN-examples slide 6 Each buffer must be emptied before it can be used for another camera Thus the buffer is a resource that could have a queue, which should be modeled as the pseudo-task Buffer Model fragment without buffer How the buffer pool was [1.8] acquireLoop User VideoController rate=0.5/secUsers modeled [1.8] ($N) UserP acquireLoop User VideoController rate=0.5/secUsers UserP (1) (1) ($N) procOneImage [1.5,0] readCard [1, 0] (1,0) CardReader AcquireProc procOneImage [1.5,0] readCard [1, 0] (1,0) CardReader AcquireProc Applic CPU Applic CPU CardP CardP (1,0) (1,0) admit [3.9, 0.2] AccessController alloc [0.5, 0] BufferManager admit [3.9, 0.2] real task BufferManager and pseudo- task Buffer AccessController alloc [0.5, 0] BufferManager (0, 0) (forwarded) (0, 0) (forwarded) alarm [0,0] Alarm bufEntry Alarm alarm [0,0] Buffer Dummy bufEntry Buffer Dummy (1, 0) (1, 0) (1, 0) AlarmP (1, 0) (forwarded) (1, 0) (1, 0) AlarmP (forwarded) (0, 1) (0, 1) (0, 0.2) getImage [12,0] [0, 500] passImage [0.9, 0] Lock storeImage [3.3, 0] lock [0, 500] AcquireProc2 StoreProc Lock (0, 0.2) getImage [12,0] passImage [0.9, 0] storeImage [3.3, 0] lock AcquireProc2 StoreProc ($P, 0) LockP ($P, 0) (1, 0) (1, 0) LockP (1, 0) (1, 0) readRights [1.8,0] network [0, 1] releaseBuf [0.5, 0] writeImg [7.2, 0] writeEvent [1.8, 0] Network (infinite) BufMgr2 DataBase (10 threads) readRights [1.8,0] network [0, 1] releaseBuf [0.5, 0] writeImg [7.2, 0] writeEvent [1.8, 0] Network (infinite) BufMgr2 DataBase (10 threads) (0.4, 0) (1, 0) ($B, 0) (0.4, 0) (1, 0) ($B, 0) forwarding call to a function of BufferManager DB CPU DB NetP CPU Disk (2 threads) readData [1.5, 0] writeRec [3, 0] writeBlock [1, 0] NetP Disk (2 threads) readData [1.5, 0] writeRec [3, 0] writeBlock [1, 0] DiskP DiskP

  7. Handling of Buffering (2) acquireLoop SYSC4102/5101 LQN-examples slide 7 User VideoController rate=0.5/secUsers [1.8] The operations that require holding the buffer are executed by calls from the buffer pool pseudo-task Buffer separate from the buffer manager task!! including the execution of the release operation by the buffer manager assumes the manager has a dedicated thread for release releaseBuf is executed by storeImage, or bufEntry UserP (1) ($N) procOneImage [1.5,0] readCard [1, 0] (1,0) CardReader AcquireProc Applic CPU CardP (1,0) admit [3.9, 0.2] AccessController alloc [0.5, 0] BufferManager (0, 0) (forwarded) alarm [0,0] Alarm bufEntry Buffer Dummy (1, 0) (1, 0) (1, 0) (forwarded) AlarmP (0, 1) (0, 0.2) getImage [12,0] passImage [0.9, 0] storeImage [3.3, 0] lock [0, 500] AcquireProc2 StoreProc Lock ($P, 0) LockP (1, 0) (1, 0) readRights [1.8,0] network [0, 1] releaseBuf [0.5, 0] writeImg [7.2, 0] writeEvent [1.8, 0] Network (infinite) BufMgr2 DataBase (10 threads) (0.4, 0) (1, 0) ($B, 0) DB CPU NetP Disk (2 threads) readData [1.5, 0] writeRec [3, 0] writeBlock [1, 0] DiskP

  8. Model Features SYSC4102/5101 LQN-examples slide 8 This model illustrates how we can model logical resources (the buffer pool) the use of forwarding the use of second phase to improve concurrency (later)

  9. Results #1 SYSC4102/5101 LQN-examples slide 9 Average Response Time Cycle (sec)User (sec) AcqProc 0.327 0.127 0.655 0.138 0.983 0.133 1.310 0.129 Normalized Utilizations Prob of Missing Deadline Ncam Buffer StoreProc AppCPU Cameras Doors 10 20 30 40 0.960 0.963 0.964 0.965 0.9998 0.9999 0.9999 0.9999 0.582 0.582 0.582 0.582 0.549 0.545 0.544 0.544 0 0.031 0.036 0.038 0.034 0.0007 0.4196 0.9962 Table 1. Simulation results for the base case Base case, one buffer, so one camera at a time Access-control responses are fine; the event rate was kept constant at 2/s. Camera polling becomes too slow between 20 and 30 cameras try adding more buffers.

  10. Results #2 SYSC4102/5101 LQN-examples slide 10 cameras fixed at 40, vary the number of buffers NBuf disappointing: the miss probability levels out above 9% at about 7 buffers. StoreProc is apparently the new bottleneck: try an additional thread Average Response Time Cycle (sec) 1.309 1.016 0.941 0.911 0.879 0.872 Prob of Missing Deadline Normalized Utilizations NBuf User (sec) 0.137 0.132 0.132 0.131 0.132 0.129 AcqProc Buffer StoreProc AppCPU Cam s Doors 1 2 3 4 7 0.965 0.975 0.980 0.983 0.986 0.987 0.9999 0.8762 0.8235 0.8042 0.8136 0.8437 0.583 0.800 0.893 0.936 0.984 0.995 0.544 0.702 0.756 0.782 0.810 0.817 0.9961 0.5503 0.2506 0.1597 0.0948 0.0935 0.034 0.032 0.036 0.032 0.033 0.034 10

  11. Results #3 SYSC4102/5101 LQN-examples slide 11 Success! Two threads on StoreProc combined with 4 buffers brings the miss probability down well within spec of 1 second for each 40 cameras, Nuser = 100 doors, Nbuf = 4 buffers Average Response Time Prob of Missing Deadline No. of Store Proc Normalized Utilizations Cycle (sec) User (sec) AcqProc Buffer StoreProc AppCPU Cam s Doors 1 2 3 0.911 0.756 0.743 0.131 0.137 0.139 0.983 0.946 0.932 0.8042 0.5805 0.5484 0.936 0.616 0.441 0.782 0.940 0.956 0.1597 0.032 0.0022 0.035 0.0015 0.039

  12. Discussion SYSC4102/5101 LQN-examples slide 12 The saturated resource is AppProc making multiplicity = 2 allows 50 cameras The limitation is now at AcquireProc, due to a long service time the time it takes to store the buffers is limiting multithreading alone is not the answer To allow an earlier start on the next camera, we can put the calls from AcquireProc into phase 2, with multithreading early reply to VideoController moves the capture on to the next camera much earlier allows the concurrent phase-2 Acquire tasks to run in parallel Other adjustments are also possible

  13. Results #4 SYSC4102/5101 LQN-examples slide 13 By using phase 2 at AcquireProc and various multiplicities we can get a capacity of 100 cameras. Even more capacity can be found with StoreProc. Another exploration approach: set multiplicities at inf and see if specified delays are feasible at all, and what mulitplicity is used (= utilizattion), then work down to specified delays. 100 cameras, Nuser = 100 doors, Nbuf = 10 buffers Average Response Time Prob of Missing Deadline Multiplicity (Acquire, Buffer, Store, App. CPU) 2, 4, 2, 2 2, 10, 6, 3 3, 10, 6, 3 Normalized Utilizations Cycle (sec) User (ms) Acquire Proc Store Proc App CPU 0.710 0.9995 0.0332 0.707 0.0057 0.0307 0.769 0.0005 0.0352 Buffer Cam s Doors 1.250 0.837 0.768 0.133 0.132 0.134 0.988 0.988 0.983 0.923 0.689 0.895 0.886 0.751 0.910

More Related Content