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