600 likes | 729 Views
Week 6 - Systems Engineering and Analysis. Buede ch 8 & Wasson ch 40 – Physical Architecture. Believe it or not – we’ll even apply this topic to the “Newton free” world of software! Image of “Second Life” from http://secondlifetalk.com/. Functional What the system must do. Physical
E N D
Week 6 - Systems Engineering and Analysis Buede ch 8 & Wasson ch 40 – Physical Architecture Believe it or not – we’ll even apply this topic to the “Newton free” world of software! Image of “Second Life” from http://secondlifetalk.com/.
Functional What the system must do. Physical How the system will do it. Buede starts here – for Wasson, see slide 47! Functional vs. Physical
Physical Architecture • Provides system resources for every function in the Functional Architecture Resource types : • Hardware • Software • Facilities • People • Procedures
Physical Architecture-2 • Must be a Physical Architecture for each system associated with the system life cycle. • Two types of Physical Architectures : • Generic and Instantiated.
Physical Architecture-3 For software: • We are used to having a design experience that feels free of physical limitations! Don’t like the way the world actually looks? Add/change/delete your own features! Image from http://www.indiamike.com/india/chai-and-chat-f73/nasa-world-wind-software-t12187/
Physical Architecture-4 For software: • “Physical” means “real” – like: • What families of components would we choose? • What “bottom up” characteristics would fit? • Without going all the way to naming those pieces • But this is systems engineering, and we also can learn from design work that does have some physical reality…
Generic Physical Architecture for Elevator Figure 8.2
Functional Allocation: 1-1 and ‘Onto’ Figure 8.4
Functional Allocation Goal • Allocate Functions Components. • There is great advantage to having Functional and Physical Architectures match (one-to-one and onto).
Functional Allocation Goal • There is great advantage to having Functional and Physical Architectures match (one-to-one and onto). • When does this happen ?? • When does this not happen ?? Product or system architecture decisions ??
Two Levels of Physical Architecture • Generic physical architecture: description of the partitioned elements of the physical architecture without any specification of the performance characteristics of the physical resources that comprise each element • Instantiatedphysical architecture: generic physical architecture to which complete definitions of the performance characteristics of the resources have been added
The Process • Generic Physical Architecture provides ‘common designators’ for physical resources. (No real physical items). • Morphology Box to create and list instantiated architectures – options for choice. • Create many alternate instantiations to choose from.
Morphological Box for Hammer (Top row – generic components, 320 possible combinations) Table 8.3
Morphological Box for Auto Navigation Support System Figure 8.5
We can use morphological boxes with software, too Image from http://hcil2.cs.umd.edu/trs/2004-17/2004-17.html
Pairwise Infeasible Combinations within a Morphological Box Hammer Example Figure 8.6
Matches first level Functional decomposition Compare lower levels to functional decomposition Is it 1-to-1 ??
Block Diagrams of Physical Architecture(Most common graphical representation) Figure 8.7
Block diagram for software Image from http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=hdwr&db=bks&fname=/SGI_EndUser/RASC_UG/ch04.html.
Issues in Physical Architecture Development • Functional performance, availability (cost, safety, fault tolerance), and other system-wide traits. • Commercial and ‘product line’ factors. • Operational architecture finishes this process. • Looking ahead – physical architecture elements are added as mechanisms on the Functional Architecture to produce the Operational Architecture.
Vehicle Theft Deterrence See https://www.youtube.com/watch?v=Ee3L9BQQ4Gs It’s fairly easy to understand conceptually how an effective system could work…
Major Conceptsfor Physical Architecture • Centralized vs. Decentralized • Modular vs. Integral • Standardization, Serviceability • ‘COTS’ components
Mostly Software Example :FBI Fingerprint Identification System • IAFIS: Integrated Automated Fingerprint Identification System • ITN/FBI: Identification Tasking and Networking segment – focus of this case study • III/FBI: Interstate Identification Index segment • AFIS/FBI: Automated Fingerprint Identification System segment
ITN/FBI: Identification Tasking and Networking • RFP identified subelements • TPS: Ten-print Processing Subelement was key • Processed paper cards with 10 fingerprints • Organized as work stations within a workgroup (distributed system) • Processed ~ 30,000 per day • Scanned, converted to binary data, and analyzed • Images had to be compressed by at least 10 to 1 • Average time to perform a fingerprint image comparison was 60 seconds • Time allowed for display of human-machine interface was 1 second from time of request
Critical Design Issues for TPS • Implementation of wavelet scalar quantization (WSQ) algorithm (hardware vs. software) • Workstation capabilities • Server capabilities • Workflow management capabilities • Communications interface
Alternate Design Allocation Options Studied Figure 8.8
Morphological Box of Instantiated Design Option 2 new alternatives (g & h) identified Table 8.5
Use of Redundancyto Achieve Fault Tolerance • Hardware: adds extra hardware to enable detection of and recovery from errors • Software: N-version • N different software developers for same routine • Comparison of results via voting • Seldom used due to expense of software development • Information: adding extra bits of information to enable error detection • Time: replaces hardware or software redundancy when there is slack processing time - recalculation
Hardware Redundancy -A crucial choice for software • Passive: extra hardware operating concurrently using voting • Errors are masked or hidden (system unaware) • Approaches • N-modular redundancy (NMR) • Triplicated: TMR – masks 1 error • 5MR – masks 2 errors • Triplicated NMR • Active: detects errors, confines damage, recovers from errors, & isolates/reports fault • Duplication with comparison: extra hardware with comparison, not voting • Hot standby: extra hardware, only one reporting, monitor of outputs to detect error • Cold standby: extra hardware inactive until error detected • Pair-and-a-spare: Duplication with comparison & hot standby • Hybrid: combinations of the above
TMR & Triplicated TMR Voter is single point of failure Issues with Voting Figure 8.9
Software Implementation of Triplicated TMR Figure 8.10
Active Hardware Redundancy: Duplication with Comparison Figure 8.11
Hot Standby Sparing, N-1 Replicas Figure 8.12
Pair-and-a-spare Figure 8.13
Practicality of Redundancy • How practical is redundancy ? • In your car. • In an airplane.
Redundancy Warning • Redundant components and systems must truly be independent systems. • Often a ‘single point of failure’ takes out all ‘redundant’ systems. • Space Shuttle Challenger (o-rings) • Genesis space vehicle (g-switches) • UA 232 Sioux City (hydraulic systems) (P.242)
Discussion Q1 • The physical architecture for the hammer : • what does the functional architecture look like
Discussion Q2 • For the drink machine functional architecture, does Hatley Pirbhai or ‘Energy, Materials, Signal Flows’ ‘work better’ with respect to giving a functional architecture that produces a ‘more realistic’ physical architecture.
Discussion Q3 • For the ATM machine, develop an external systems diagram and a first level function decomposition for the Acme ATM Company – a manufacturer and seller of ATM machines. • Consider the possible uses of the functional model and physical implementations of the system.
Discussion Q4 • Given the first level decomposition for the ATM machine: • Sketch the generic physical architecture • Sketch a morphological box and some possible instantiated physical implementations
Wasson’s Ch 40 Let’s look at Wasson’s recommended methodology:
Wasson’s “Domain solution challenges” (Sec 40.6) Solution space validation Technical design integrity Multi-domain solution agreement Risk identification and mitigation Environment, safety and health System solution stability System support Interfaces System optimization Phases and modes of operation
Extra Slides See the last slide!