Transcript System Design Examples

Principles of
Engineering System Design
Dr T Asokan
[email protected]
System Design Examples
Contd..
InSeKTs
Railway
service
Airways service
Satellite GPS
And weather
Supplier
Transmission
Customer
support
User
Telephone
Printer
Fax
Internet
Server
and
Database
IDEF0 (Integrated Definition for Function Modeling)
A0 diagram
Type of User:
Visitor/IITM
community
Database
User request
for directions
Destination
Request to
Print Map
Acknowledgement
that Request was
received
Current Location
Electric Power
Service, Tests and
Repair
PROVIDE
DIRECTIONS AND
OTHER NAVIGATION
DETAILS
Directions from
current location
to Destination
Printed Map
InSeKTs
Maintenance
Services
A0 Diagram
Database
Electric Power
Service, Tests
and Repair
Type of User:
Visitor/IITM
community
User request
for directions
Destination
PROVIDE DIRECTIONS
AND OTHER NAVIGATION
DETAILS
Request to
Print Map
Acknowledge
ment that
Request was
received
Current
Location
Directions from
current location
to Destination
Printed
Map
InSeKTs
Maintenance
Services
User Request
for directions
Power Supply
Acknowledge
Request
Accept Request
Process Request
Database
Digitized Request
Search in Database
Electricity
Find routes
Display
directions
Print Map
Maintenance
InSeKTs
A11 DIAGRAM
User
Request for
direction s
Pow er
Supply
Ackno wledg
e Req ue st
Accept
Re quest
Process
R equest
D igitized Request
D atab ase
Search in
Database
Electricity
Find
po ssible
routes
Display
directions
Print M ap
M aintenance
InSeKTs
A111 DIAGRAM
U s e r re q u e s t
fo r d ir e c t io n s
D a ta b a s e
A ccept R e quest
D ig itiz e R e q u e s t
A c k n o w le d g e
R equ est
In S e K T s
InSeKTs
User
Interface
Components
Communication
module
GPS/Navigation aids
keyboards
Touch screen
Telephone
Receiver
Transmitter
Speaker
Processor
Display Screen
Database server
Printer
Fax
Network
components
Power
module
MORPHOLOGICAL BOX
DISPLAY
Telephone
Network
Printer
Directions
Database
Local AreaNetwork
CRTMonitor Chordless
© Airtel
Dot Matrix
Mapand
Database
©Operational
Database
Ring
LCD
©
WithChord
Vodaphone Ribbon
Data
Warehouse
Master-SlaveorPipeline
ELD
Mobile
Idea
©InkJet
©Map,
Database
Routing
Algorithm
StaffedControl
center
Analytical
database
BUS
GasPlasma
Display
Aircel
Laser
Automated
Control center
Distributed
database
©
STARor SPOKE
© Touch
Screen
Reliance
Line
End-User
Database
MESH
TATA
External
database
Hypermedia
Databases
REDUNDANCY REQUIREMENTS
Fault detection:
•User support/feedback system fails
•Access to printer/fax/telephone fails
•Power supply system fails
•Transmitter fails
Transmitter fails: for satellite GPS - Using hot standby sparing
Transmitter1
error
Signal from
satellite
Transmitter1
Control
Unit
error
Transmitter1
error
maps
User support/feedback system fails: Users maybe accessing from different
locations - Using triplicated TMR
User1
User2
User3
Connecting
uint1
Supportunit
support1
Connecting
uint2
Supportunit
support2
Connecting
uint3
Supportunit
support3
Access to printer/fax/telephone fails - Using cold standby Sparing
Information
Printer1
Error
or
Printer2
Error
or
Control
Unit
Printout
Power supply system fails - Using cold standby Sparing
power signal
Power
Error
or
Power
Backup
Error
or
Control
Unit
Power tosystem
Weightage allocation for Contact details of IITM residents
InSeKts
Maintenance (0.35)
Operational Objectives (0.65)
Power cost for
Database (0.2)
Maintenance Cost
(0.2)
Software Update
Costs (0.3)
System protection
updates (0.2)
Kiosk Security (0.1)
Storage Capacity (0.2)
Number of simultaneous
enquires handled (0.05)
Speed of data transfer (0.2)
Speed of the system (0.15)
Security for sensitive data (0.2)
Ease of use (0.2)
UDaReS
Unified Data Recording System
SYSTEM DESIGN: Example 3
UDaReS
Unified Data Recording System
1.0 Mission:
To develop a unified data-recording system to monitor and control the
academic, administrative and other day-to-day activities across the
campus.
2.0 Objectives:
•Online recording and compilation of attendance for students/staff/faculty on a day-today basis.
•Real time analysis of slot-wise engagement of students/faculty.
•Online compilation of student grades and TCF.
•Integration with the online database of central library.
• Serve as a real time data base for leave/salary/scholarship
computation.
• Monitor usage of various facilities like mess/SFC/ Gym/swimming
pool etc. by the students/staff.
• Record faculty/student/staff usage of common services like hospital,
engg. unit etc. of the institute and usage of the data for futuristic
planning.
• Enable cashless transactions at various campus stores.
• Develop an online database for projects undertaken by IC&SR and
provide online access to financial information.
F a c u lty /S t u d e n t s /
S t a ff
C am pus
S e r v ic e s
S tu d e n t
F a c ilitie s
L ib r a r y
U -D a re
s y s te m
N e tw o r k
S y s te m
IC & S R
G ym khana
A d m in is t r a t io n
System Context diagram
UDRAE Life cycle
DEVELOPMENT PHASE
Type of scanners, number of
scanners, method of
communication, processing
techniques
ASSEMBLING PHASE
RETIREMENT PHASE
No. of years before the
scanners need to be replaced.
No. of days before old records
are revised etc.
Assembling various subsystems,
configuring networks, connecting
subsystems to main system
UDARES LIFE CYCLE
REFINEMENT PHASE
No. of updates in the software, scope
for new facilities and added
functionalities. No. of days before
system requires a status update, No.
of new features in the software,
Sensitivity refinements of scanners,
network refinements etc.
TESTING PHASE
Test the working of varoius
subsystems individually and
collectively to check process
parameters
DEPLOYMENT PHASE/OPERATIONAL PHASE
Setting the system to
work creating
student/staff/faculty records,
retrieving records etc.
MAINTENANCE PHASE
No of regular checks on the system,
Repair time and recuperation time for
system etc.
3.0 Scope of Project:
The project will be limited to:
1. Limited data recording and retrieval by students
2. Data recording by all the staff and limited retrieval
by authorized staff.
3. Unlimited data entry and limited retrieval by faculty.
4. Cashless transaction at select establishments/
centres only.
4.0 System Operation
Few typical operational scenarios are listed to
elaborate on the system functioning.
Scenario 1. Faculty records daily attendance.
• An input data device (portable) connected to the
network (through cable/wireless) display the options
available
• Faculty chooses attendance record
• System asks for authentication
• Faculty provides authentication
• System accepts authentication and displays the
options available for the faculty
• Faculty chooses course name
• System display student name and offers opportunity
for faculty to enter data.
• Faculty enters data and completes the process by
logging out.
Updating student attendance on a day-to-day basis
Professor
Request to access with portal
Feedback for authentication details
Enter authentication details
Feedback regarding authentication accepted
Request to enter course number
Enter the course number
Feedback regarding course number accepted
Request to enter date of attendance
Enter the date of attendance
Display the database
Enter the attendance details of students
Feedback stating details were accepted
Request to log out of the portal
Feedback on successful logging out
U-Dares
Originating Requirements Document (ORD):
Operational Phase
1. Input/Output Requirements:
• The system shall accept identification details from
professor/students/staff.
• The system shall give feedback to user within
x seconds.
• The system shall display fonts at least to the
size of ‘y’
• The system shall have provision to enter fees
payment details by the bank personnel
• The system shall have provision for auto generating
mail for request of slot exchange with other faculty
• The system shall have provision to send mail to
students notifying them regarding scholarships etc.
•The system shall compile the staff attendance data
•The system shall send mail to the students
regarding changes in the class schedules
Technology/ System wide requirements:
• The system shall auto-save data every 30 seconds
•The system shall allocate 1Gb space for every
faculty, 500Mb space for every student/staff
• The system shall have a processing speed of 5GHz or
more
•The system shall use Ipv6 protocol for networking
Use U-Dare
Services
Software
regulations
Request
U dare Services
Maintenance
system
Provide UDare Services
Provide support
Computers
Students
Staff
Faculty
Main
server
Maintenance
personnel
EXTERNAL SYSTEM DIAGRAM
Seminarinfo
Requestfordesired
Anamolycheck
dataservice
askforinfo
Requestfor
service,
input,
password,
course-idetc.
Displayseminar
Provideservice
Useservice
feedback
a.c.,supportetc
Provideinfo
Keepcheckon
functioningof
system
giverequiredinfo
Monitoroperations
Faculty/staff/students DHU
Server
Adblock
EXTERNALSYSTEMDIAGRAM
Software/hardware
check
Maintenance Housing DisplayUnit
A-0 Context diagram
Username/ password
Request slot exchange/extrahour
Attendancedetails
Updatedattendancedatabase
Grade/scholarshipinfo
Mail request forslot exchange
ProvideU-DARES
Services
Lit-socevent schedule
Slot wiselisting
Scholarshipallotment andrenewal
UpdatedLit-Socallotment database
Recordedstaff attendance
A0
Feesdatabase
User Identity
Authentication
A1
Accept User
A2
Request
Provide Services
A3
User Identity
Authentication A4
Maintain
Services A5
A0 diagram:
Networkdatabase
Datasearch
request
Navigation
request
Cashless
transaction
request
User Identity
Authentication
(A1)
Power supply
Feedback
Accept user
request/provid
efeedback
(A2)
Displaydata
Providenavigation
services
Control
operation(A3)
Enablecashless
transaction
Provideutility
services(A4)
Maintenance
andrepair (A5)
Maintenance
services
UDARE
SYSTEM
Proper functioning
A3 diagram:
Network database
Data search
request
Navigation
request
Cashless
transaction
request
Power supply
Feedback
Process
request
(A31)
Search for
data(A32)
Provide navigation
details
Extract data
(A33)
UDARE
Display
information
Transactiondetails
A32 diagram:
Network
database
Login and
password
Power
supply
Connect to the
network (A321)
Search for desired
data in the network
database (A322)
UDARE
Extract data from
the network
A322 diagram
Network
database
Connect to the
network
Power supply
Find the category
of the information
asked by the
user
A3321
Collect data from
the corresponding
category
(academic/
administrative/
general) A332
UDARE
Extract
data
Level-1
function
PROVIDE U-DARE
SERVICE
User identity
Authentication
A1
A11
Accept user
request/ provide
feed back
A12 …A21
Control
operation
A4
A3
A2
M aintenance
and repair
Provide services
A41
A42
A43 … .
A22 A23
Extract data
Process request
Search data
A32
A33
A31
A311
A331
A312
Connect to network A321
A51
A52 A53 …
Level-2
function
A332
Search for data in
database
A5
Level-3
function
A322
A3211 A3212 A3213 …
Find the category of
Collect data
infunction asked by
user
A3121
Lower-level
function
A31211
A31212
A31213
A31221
A3122
A31222
A31223
UDARE System
DATAgathering Compilation,
(0.3)
updating
of data(0.3)
Displaying/
providing
data to
users(0.2)
Additional
features
(0.1)
Maintenance
security(0.1)
Speed of
process
(0.2)
Speed of
process(0.3)
Features
shown(0.5)
Facility to
search(0.3)
Maintenance
cost(0.5)
Accuracy of
data gathered
(0.5)
Consistency of
compiling and
updating(0.7)
privacy of
users’
data(0.2)
Availability/
accessibility of
extra features
(0.7)
Updating of
security
system(0.3)
Maintenance
of gathering
devices(0.3)
Users’
ease of
using/
displaying
(0.3)
Power
consumption
in the
process
Morphological Boxes:
Bluetooth
Wi-Fi
LAN
Wi-Max
Password
Plastic
Metal
Polymer
Iris eader
FRP
Fingerprint scan
Vinyl Coated Paper
Photo-verify
Voice
recognition
Morphologicalbox:
Information processing Nodes Network Information Information Information Error
Error
Threat
Threat
exchange component
architecture displaying entering processing detection correction correction detection
component component component component component component component component
SQL
server
16bit
5GHz 250 Node
15.4”
branching= CRT
5
screen
64
2GHz
character
keypad
SQL
server
32bit
10GHz 400 Node
17”
branching= LCD
10
screen
Symantec 1.66GHz Oddparity Oddparity
touchpad
check corrector
detector
Evenparity Evenparity Customizable virusscan
check corrector anti-virus
detector
firewall
Interface Design
Interface requirements: Transfer of data between
different modules.
Operational concept: Intranet (LAN based system).
DHUs---------------Server--------------Display unit
System shall have shared memory network with
storage at server.
Interface options
• wi-fi
• Using LAN cables
• Telephone connection
• Wi-fi is too expensive. Data transfer is slow.
• Telephone connection is slow.
• LAN cables are already present in almost all the
rooms. Fast and cheap.
•Select LAN
Integration and qualification
Supplemental topics
•
•
•
•
•
Graphical modelling techniques
Decision analysis for design tradeoffs
Uncertainty in decision making
System reliability
Statistical tools for system design
THANK YOU