Systems engineering: It’s anenabler
Presentation at Orbotech 7 March 2011Dr Joseph Kasser, CEng, FIET, CM, CMALT
1
Assumptions
You know something about systemsengineering Talking about philosophy to make you think about
the way you apply it
You do not know about amateur radio The application domain in the case study
You understand enough English tounderstand this talk Example of importance of stating assumptions Facilitates communications
2
Topics
Systems engineering camps Gaps in what we teach
Case study extract Pointing out some of the gaps
Lessons learnt from the case study Systems engineering: an enabler
3
What is systems engineering?
4
The systems engineering camps
The process camp Functional perspective
The discipline camp Structural perspective
The problem camp Operational perspective
The activity camp Functional/operational perspective with an
objective definition 5
Parable of blind men and elephant*
“… And so these men of IndostanDisputed loud and long,Each in his own opinionExceeding stiff and strong,Though each was partly in the right,And all were in the wrong!
MORAL.So oft in theologic wars,The disputants, I ween,Rail on in utter ignoranceOf what each other mean,And prate about an ElephantNot one of them has seen!”
* Yen, D. H., The Blind Men and the Elephant, 2008,http://www.noogenesis.com/pineapple/blind_men_elephant.html, last accessed 26 October 2010 6
A matter of perspective.
Functional andoperational
Takeover the
world
Process
Functional
Problem
Operational
Perspectives areincomplete andthere are gaps
7
Topics
Systems engineering camps Gaps in what we teach
Case study extract Pointing out some of the gaps
Lessons learnt from the case study Systems engineering: an enabler
8
Amateur radio - context World-wide hobby Licensed by governments National societies
American Radio Relay League (ARRL) Radio Society of Great Britain (RSGB) Singapore Amateur Radio Transmitting Society (SARTS)
Experimenting and applying Emergency communications, terrestrial, satellite, hardware,
software, business, etc. Platform for developing systems engineers*
http://www.youtube.com/watch?v=nd0tTYgJWEo
* Kasser, J. E., "How synergy between amateur radio, systems and other engineeringcan raise the technical quotient of a nation", proceedings of the 4th Asia-PacificConference on Systems Engineering (APCOSE 2010), Keelung, Taiwan, 2010.
9
Big picture - context Simulated emergency message traffic
handling Contest format Exchange messages simulating traffic into
and out of simulated disaster zone World-wide contests
Everybody contacts everybody Local and regional contests
US Sweepstakes, Australia, BERU, etc. Target area contests
Everybody tries to contact stations in a given area US State QSO parties, ARRL DX, SAS, WAE, etc.
Go back in time to 1977/8 10
ARRL Sweepstakes contest[1977]
Contact (work) as many other stations aspossible within 48 hour period Weekends in November
Exchange simulated emergency message Use different frequency bands with different
propagation characteristics Score = number of contacts * multiplier
Multiplier is number of ARRL Sections contacted Section only counts once irrespective of frequency band
11
Big picture - lifecycle
A1
12
Column A: a systems engineeringapproach to problem solving*
1. Plan the work (Tasks 2-8)2. Define the problem3. Conceive solution options4. Identify ideal solution evaluation
criteria5. Perform trade off to find the
optimum solution6. Select the preferred option7. Formulate strategies and plans to
implement the preferred option8. Milestone review to obtain
authorisation to proceed toimplementation phase
Recursive or self similar Applies to each box Fits in one column of the
HKMF Fits across several columns
of the HKMF
* Tasks 2-7 from Hitchins, D. K., Systems Engineering. A 21st Century Systems Methodology, John Wiley & SonsLtd., Chichester, England, 2007., Figure 6.2
1 23
45 6 7 8
13
Focusing in on the problem Problem had been recognized
at least 12 years earlier The time was 1978 Understand the factors
involved in the ARRLsweepstakes contest wellenough to enable an operatorin Silver Spring, MD to contactall the Sections (multipliers)given the constraints of lowradiated power
Key words in red
Technologymay enableor prohibit
solution
Problemstatement is
different
Reliance ontechnology
14
Exploring solutions to determinereal need
1. Read about factors
Identify the factors Identify relationships
between factors Develop understanding
2. Create contest simulation
Identify the factors Identify relationships
between factors Develop understanding Create simulation Run simulation
Try approaches andsee what happens
Develop betterunderstanding 15
Radio Propagation
My QTH
Distant Section
Ground wave
Sky wave
(refraction altitude dependent on frequency and time (solar effect)
Interference
16
ARRL Sections in 1977
Note: Numbers are assigned for this project not by the ARRL 17
The pertinent factors
The Sections 75, spread out across CONUS, and non-CONUS
Probability of propagation to Section Radio frequency band Time of day
Probability of someone in Section when wanted Population distribution
Probability of interference from other stations Transmitted power Receiver front end characteristics
18
Statement of the problem
Develop a simulation that is:1. Realistic enough to enable an operator in
Silver Spring, MD to contact all theSections given the constraints of lowradiated power if the operator hasdeveloped an understanding of thepertinent factors involved in contacting allthe Sections.
2. Fun to play.
Realistic enough to enablesuccessful completion ofmission at the appropriate
time 19
Feasibility study: Constraints(implementation domain knowledge)
INTEL Hardware platform Given constraint 8080 microprocessor (8 bits)
Assume software written in BASIC Memory
32K RAM Interpreter occupies 16K Bytes
Need some space for Stack and run timevariables
Leaves about 14K Bytes for program 20
Feasibility study: Risk management(implementation domain knowledge)
Do some software code size estimation Table of Stations callsign array is largest data element
(need to know there are 2707 maximum from published scores)
Conclusion – feasible but with implementation risk RAM Memory may be insufficient
Risk mitigation possibilities Use spaghetti code to cut down on memory use
Document source code accordingly, REM statements are discarded byinterpreter
Use IBM 360 if code won’t fit in Intelec MD8/80 TPM: RAM usage – track during software development
Domain knowledge is software programming and PC platform
We often decouplehardware and
software development(Except in embedded
systems)
21
1977 Published scores*
* QST, May 1978, page 68 22
What the operator does
Contactsomeone Exchange data Store dataStart
End
Contestover ?*
YesNo
Time out(0-n minutes)
* Contest over := (24 hrs of operation [elapsed time]) or (end time GMT) 23
Functional flow diagrams
Start documenting and expanding ideas Intuitive Identify sequences Functions can be simple or complex Identify dependencies between functions May not provide best grouping Are a tool to provide a view May not be best tool to create relationships
between functions24
Alternate Function flow chart –Call CQ (OS1.1) functionalperspective
Call CQ Reply?Yes
Receive message
Send Worked B4
Send Message
Duplicate?
Complete?
Request repeat
Store data Say ‘Bye’
Enough?Yes
Yes
Yes
25
Function flow chart – Call CQ(OS1.1) functional perspective
Call CQ Reply?Yes
Send Worked B4
Exchange data (QSO)
Duplicate?
Store data Say ‘Bye’
HadEnough
?
Yes
Yes
No
No No
26
Exchange data (QSO) (1)functional perspective
Receive message2Send Message1
Complete?
Request repeat
Yes
Note 1, sending station may also request you to resend messageNote 2, message may be incomplete due to interference
27
Exchange data (QSO) (2)functional perspective
Receive message2
Send Message1
Complete?
Request repeatNo
Note 1, sending station may also request you to resend messageNote 2, message may be incomplete due to interference
Yes
28
Partial functional N2 chart
F_CQ o o o3
o F_RX o o1 o2 o o4
o F_CK o o o
o F_B4 o
o F_TXM o o o
o o F_RXM o o
o F_LOG o
o F_QSY o
o o o F_QRV
Outputs – horizontal squares, Inputs – vertical squares 29
Partial functional N2 chart
F_CQ o o o3
o F_RX o o1 o2 o
o F_CK o o o
o F_B4 o
o F_TXM o o o
o o F_RXM o o
o F_LOG o
o F_QSY o
o o o F_QRV
outputs – horizontal squares, inputs – vertical squares
F_QSO
Single input, candidatefor aggregation
Candidate foraggregation with F_QSO
May needa new
interfacefunction
here
30
How do you determine systemfunctions?
Top down? Bottom up? Middle out? All of the above Tendency to flowchart functions N2 chart is better way Both approaches is best way
Checks and balances31
Do we need requirements?
Size of project Very small
Concept of operations Well understood
Likelihood of changes during SDLC Very low
Number of people/organizationsinvolved 1
32
Requirements analysis -1:Requirement for number of stationstaking part
Published scores showed maximum number ofcontacts was 2707 for top scorer
Requirement600. The system shall contain at least 2707 stations.
Can set number at 3000 (TPM: watch RAM usage, and drop to 2710 if necessary; use
parameter for value)
Feasibility analysis (maximum) 3,000/24=125 contacts/hour = 2/minute
Reasonable (application domain knowledge)
Critical:customer
involvement
33
Requirements analysis -2:Requirement for number of stations ineach Section
Published scores in QST list participation by Section Two separate parts (weekends) to contest
Phone (SSB) and Morse code (CW) Set requirements for stations in each Section based on
1. SSB participation2. CW participation3. Combination participation in the two parts
Assumption Ratio of number of stations not submitting entries is about the
same as for those submitting entries
1 23
45 6 7 8
34
Requirements analysis -2:Number of stations in eachSection
Selection criterion At least one station in each Section? If none of the options contains at least one station, then
a station may need to be inserted – see next slide foroptions.
Criteria CW SSB Combined
At least one in eachSection
No No Yes
Missing Sections WY,NWT CZ None
1 23
45 6 7 8
35
Dealing with WY, NWT and CZ(1 participant)
Options1. Set value at 1 (published results)
For all iterations of simulation
2. Set value at either 0, 1 or 2 At start of each iteration of simulation
Selection criteria It’s a simulation, numbers are small, should
have minimum effect Makes game more interesting (and real?)
Uncertain if a ‘clean sweep’ can be achieved
1 23
45 6 7 8
36
630. Requirements for number ofstations in Canada1
631 The system shall contain 7 stations in MAR2.632 The system shall contain 8 stations in QB.633 The system shall contain 16 stations in ONT.634 The system shall contain 9 stations in MAN.635 The system shall contain 3 stations in SK.636 The system shall contain 7 stations in AB.637 The system shall contain 8 stations in BC.638 The system shall contain 0, 1 or 2 stations in NWT.
Notes 1Numbers are determined by distribution expect for NWT
2 See Section TBD for abbreviations37
Looking back at the problemstatement
Number of stations in each Section that is needed for theunderstanding? Exact or relative?
Let the number of stations in each Section vary by asmall percentage each time the simulation is run Make simulation game more interesting Makes for a different situation Valid
distribution was assumed based on 1 set of entries there was an assumption on the distribution in slide 64
Put ± tolerances on the stations in each Section
38
630. Requirements for number ofstations in Canada1
631 The system shall contain between 6 and 8 stations in MAR.632 The system shall contain between 7 and 9 stations in QB.633 The system shall contain between 14 and 18 stations in ONT.634 The system shall contain between 8 and 10 stations in MAN.635 The system shall contain between 1 and 4 stations in SK.636 The system shall contain between 6 and 8 stations in AB.637 The system shall contain between 7 and 9 stations in BC.638 The system shall contain 0, 1 or 2 stations in NWT.
1. Tolerances from application domain knowledge39
Alternate approach to settingrequirements for number of stationsin Canada
Use probabilistic approach and calculate for each iterationof simulation Section calculation approach (F_Section)
Test feasibility of requirements Calculate percentage of entries in each Section in contest from
published results Whole contest or by call area (easier to manage)
Write software module to set up distribution of Sections based oncalculated percentages (± tolerance, allowing for a 0 value)
Exercise module several times and compare results of model topublished data from results to validate module
Write requirements to allow for both design approaches
40
Partial published resultsCW SSB TOTAL % CANADA % CONTEST
MAR 4 3 7 11.86 0.26QB 6 2 8 13.56 0.30
ONT 10 6 16 27.12 0.59MAN 6 3 9 15.25 0.33SK 2 1 3 5.08 0.11AB 2 5 7 11.86 0.26BC 4 4 8 13.56 0.30
NWT 0 1 1 1.69 0.04SUM 34 25 59 100.00 2.19
41
630. Requirements for number ofstations in Canada1
631 0.26±p% of the stations in the contest shall be in MAR.632 0.30±p% of the stations in the contest shall be in QB.633 0.59±p% of the stations in the contest shall be in ONT.634 0.33±p%of the stations in the contest shall be in MAN.635 0.11±p% of the stations in the contest shall be in SK.636 0.26±p% of the stations in the contest shall be in AB.637 0.30±p% of the stations in the contest shall be in BC.638 0.04±p% of the stations in the contest shall be in NWT.
p% TBD42
Functions and requirements
Function Contact stations in Canada
Requirements Specify the number of stations in each Section in
Canada
Requirements are one way to quantify functions And ..
43
Requirements analysis 3:Platform dependency
101.1 The simulation shall be written in MicrosoftBASIC Version 2.0.
101.2 When executing, the simulation shall becontained within 12K Bytes of RAM.
101. The simulation shall execute on an INTEL Intelec8/80 Microprocessor Development System equippedwith 32 K Bytes RAM.
[That is the maximum RAM for that architecture]
OR
44
Tools and techniques used inrequirements analysis (summary)
Looked up data in application and execution domains Used domain data to compute values for requirements Developed models of probabilistic functions
Design and realized partial elements of solution system
Exercised models Tested validity of models as part of breadboarding process
Used problem solving process a number of times How the wording of requirements affects the design
45
Big picture - lifecycle
46
47
Issues addressed in this phase
Writing the code (construction) Propagation model Section distribution model
Propagation modelTime Frequency Band (M)(Hrs) 10 15 20 40 80
0000 0 0 0 100 100
0400 0 10 50 100 100
0800 100 0 100 100 0
1200 100 0 100 100 0
1600 50 10 50 100 50
2000 0 0 0 100 100
For W1/VE1 call area*
Group of sections
Limited to 10-80 M Time is EDT or Local Four hour time of day
blocks Number indicates
probability ofpropagation
* From fig 5-10 in Kasser J., Software For Amateur Radio, TAB Books, 1984, page 8348
Propagation model
Options1. Logic using IF … THEN statements2. Table driven approach
1 23
45 6 7 8
49
Logic approach2230 IF B=B4 OR B=B5 AND H<12 OR B=B3 AND H>=20
AND RND(1)>.5 THEN 28102240 IF B=B3 AND (H<20 AND H>=12 OR RND(1)>.5 AND H>=8)
THEN 28102250 IF B=B2 AND (H>=20 OR H>=8 AND H<12) AND
RND(1)<0.1 THEN 28102260 IF B=B1 AND (H>=12 AND Q=2 AND H<20 OR H>=20
AND RND(1)>.5) THEN 28102270 RETURN: REM with Y5 as 02810 Y5=1:RETURNB = Band
B1 … B5 amateur bands
H time of day [block]50
Table driven approach Use an array Contact(S, B, H)
Can be the Table of stations Section, Band, Time of day block
Code During initialization
Store Table values in Contact(S, B, H) At run time
Set up value of S, B and H Index into array by value in S, B and H and determine if contact is
possible (C1 = 1) Y5 = Contact(S, B, H) If Y5 = 0 THEN C1 = 0 ELSE If Y5 = 1 THEN C1 = 0 ELSE C1 = (RND(1) < Y5) : REM Returns Logical 0 or 1
51
Characteristics Logic approach
Does not requireknowledge of arrays
Simple set up Many lines of code for
execution time Flexible probabilities
By changing values ofvariables embedded inthe code
Table array Requires knowledge of
arrays Complicated set up Few lines of code at
execution time Flexible probabilities
By changing dataloaded into tablewithout programming
Bonus: Location can bechanged to any Section By changing data
loaded into table without programming
52
Selection Criteria
Development time Array approach has learning curve
Schedule issue
1 23
45 6 7 8
53
Decision Use logic approach
Lack of domain knowledge Schedule driven
Risk of non-completion of software
Wrong decision from a ‘systems’ perspective Hindsight Completion of simulation was secondary objective Understanding of the situation was primary
objective Table-based software is very powerful and flexible
Used later in other software
1 23
45 6 7 8
54
Topics
Systems engineering camps Gaps in what we teach
Case study extract Pointing out some of the gaps
Lessons learnt from the case study Systems engineering: an enabler
55
Lessons learned Simulations should be realistic enough to enable successful
completion of mission at the appropriate time The same problem solving process is used in all phases of the
system development lifecycle Successful systems engineering needs knowledge and experience
in/of Systems engineering, application domain, implementation domain
The customer/user needs to be involved in the development Application domain knowledge
The need to focus on what is important In M&S it is “the understanding”
Simulations don’t provide answers, they [should] provide understanding
56
More lessons learned Functional flow diagrams may not be best tool to create
relationships between functions N2 charts are powerful and versatile tools Incorrect aggregation leads to aggravation We probably don’t need as many system level
requirements as we think we do The wording of requirements affects the design Recursiveness and self-similarity of problem solving
process Technology influences design decisions There is knowledge in the development team that is not
delivered with the solution system Work should be, and can be, fun
57
Topics
Systems engineering camps Gaps in what we teach
Case study extract Pointing out some of the gaps
Lessons learnt from the case study Systems engineering: an enabler
58
Type I Type II Type III Type IV Type VKnowledge
Systems engineeringDeclarative Procedural Conditional Conditional Conditional
Domain (problem solution)Declarative Declarative Conditional Conditional Conditional
Cognitive characteristicsSystem ThinkingDescriptive
Declarative Procedural Conditional Conditional Conditional
PrescriptiveNo No Procedural No Conditional
Critical Thinking Confused factfinder
Perpetualanalyser
Pragmaticperformer
Pragmaticperformer
Strategic re-visioner
Individual traits (sample)Communications Yes Yes Yes Yes YesManagement No Yes Yes Yes YesLeadership No No Yes Yes Yes
Proposed Maturity Model for measuringcompetencies of engineer-leaders
59
Holistic thinking the problem Critical thinking
Can’t expect systems engineers to haveknowledge in all domains
Systems thinking Use continuum perspective/lateral thinking
Reverse position of knowledge
Key questions What else is used across all domains? Is there a discipline which is used in all domains?
Answer Mathematics
60
Systems engineering is anenabler Systems engineering is an enabler in “the
making things happen” function In different disciplines in different domains Applying systems thinking in problem solving Activities that deals with parts and their
interactions as a whole Similar to mathematics
61
An enabler “[systems engineering] is a philosophy and a way of
life” Hitchins, D. K., "Systems Engineering…In Search of the
Elusive Optimum", proceedings of Fourth Annual Symposiumof the INCOSE-UK, 1998.
Systems engineering is the art and science ofcreating tangible solutions to complex problems andissues… (Hitchins)
Application of holistic thinking in the workplace Product (application domain) Process (implementation domain)
62
Engineer-leaders Are those people who apply holistic thinking in the
workplace to: transform puzzling, troubling and uncertain situations into clearly
articulated problems; Identify optimal conceptual solutions; Realize those solutions within the constraints of the situation
They perform such functions defined as design, test,integration, systems engineering, and project management
They need different knowledge and skills pertaining to thedomain and the area of the HKMF in which they are working
They have various job titles (roles)
63
What is systems engineering?
64
A matter of perspective
Enabler
Holistic
Functional andoperational
Takeover theworld
Process
Functional
Problem
Operational
65
Summary
Systems engineering camps Gaps in what we teach
Case study extract Pointing out some of the gaps
Lessons learnt from the case study Systems engineering: an enabler
66
Questions or comments?
67
Top Related