2/05/12 RAMS, Systems Engineering and
Systems Thinking
Presentation for
The Joint Electrical Institutions Lecture Programme
Ravindra K Bagia
About Me
—  Ravindra Bagia
—  UTS – Faculty of Engineering and IT
—  Teaching: Systems Engineering, ILS, RAM, Project
Management, Engineering management
—  Research: Complex systems and projects
1 2/05/12 My Background
—  Electrical Engineer – evolved into Systems Engineer –
further evolved into an Academic – hope to evolve into a
genuine Systems Thinker!
—  Worked with various organisations:
—  Department of Main Roads, NSW
—  Rockwell Systems Australia
—  Boeing Australia
—  Now at the University of Technology, Sydney
—  Most of my engineering practice was on large Defence/
Aerospace projects
RAMS
—  We probably all know:
—  R = reliability
—  A = availability
—  M = maintainability
—  S = safety
—  We also probably know some impressive maths that goes with
all these
—  However – I promise I won’t bring in any equations tonight!
2 2/05/12 My Purpose Tonight:
—  Emphasise Systems and Systems Thinking in RAMS work.
—  How?
—  Talk about systems – need and requirements
—  Talk about Systems Thinking
—  Talk about Systems Engineering
—  Place RAMS in this context
—  Look at some implications of not doing so.
—  Why?
Motivation
—  Still prevalent tendency to “siloed” approaches to system
development;
—  Treatment of RAMS as a “specialty” area – useful, often
necessary, but can be problematic;
—  Tendency to advocate systemic approaches but not really
using them – leading to knee-jerk decision making
—  Tensions between project drivers and engineering drivers –
leading to poor system development – systemic approaches
“going out the window”;
3 2/05/12 Motivation
—  Remind ourselves of the importance of systems thinking to
the practice of RAMS:
—  System and context complexity
—  Limits of safety engineering being stretched
—  Significant cost and time-to-market constraints: “knee-jerk”
decision making
—  Lessons from practice – usually recorded but not really learnt
—  Locate (RE- locate?) RAMS in the systems engineering life-
cycle;
—  Explore some implications of this.
My Sources:
—  My own experience as a practitioner
—  My experience as an academic – research and teaching
—  My consulting activities – numerous organisations
—  My post-graduate students (local and international):
—  Working in relevant areas while studying
—  Doing research and work-based projects
—  Consulting me after graduating
—  RAMS scholarly literature – I have not provided specific
references tonight
—  General news sources
4 2/05/12 Some Points to Ponder
—  Modern applications demand near to 100% availability
—  Think banking systems, hospital systems, public transport systems for
example;
—  Increasing complexity and coupling:
—  Of all types: interactive, dynamic, decompositional and non-linear
complexity
—  Very difficult to consider all possible system states
—  New technology – new types of hazards and accidents
—  Decreasing tolerance of single accidents
—  Prioritising and trade-off harder – time pressures, competition…
—  Increasingly complex human-machine interactions
—  Changing public and regulatory views of safety
Some points to ponder:
—  RAMS considered specialty domains of knowledge
—  What does this mean from an institutional perspective?
—  Can R, A, M and S be considered in isolation from each other?
—  Everyone says no, but what happens in practice?
—  Can RAMS be considered in isolation from everything else?
—  What are the institutional implications of this?
—  Some program managers consider RAMS a nice luxury – neither
affordable nor always required
—  How do we deal with this, given project pressures?
—  Example from recent news: Rail system is “inefficient”: remove
excess staff e.g. guards
—  Q: Will removal of guards affect RAMS? Of which system?
5 2/05/12 Declared Wisdom
—  Talk to clients/users/other beneficiaries and victims
—  UNDERSTAND their missions and operations
—  UNDERSTAND the context and the environment for these
—  Then establish the operational requirements, including
RAMS – for the total system!
—  Create a RAMS Plan, if appropriate
—  Then ensure that a systems approach is taken leading to
holistic consideration of ALL requirements
—  Ensure good interaction between relevant organisations
—  Do this for the entire life cycle
Systems Life Cycle
Operational Requirements
Need
Conceptual
Design
Preliminary
Design
Detail
Design &
Development
Production
and/or
Construction
Utilization
and
Support
Phaseout
and
Disposal
Life Cycle Cost
Source: Blanchard B. and Fabrycky W., Systems Engineering and Analysis, Pearson, 2011
6 2/05/12 But What is a System?
—  Our working definition:
An entity comprising elements working together to achieve the
entity’s purpose.
—  Key notions:
—  Elements – socio-technical: may be complex systems in their own
right
—  Relationships – static or dynamic
—  Purpose: often multiple and conflicting, stakeholder driven, changing
over time. How do we determine a system’s purpose?
Systems Hierarchy
7 2/05/12 So What?
—  Our system is a subsystem of a larger system
—  It needs to work with other subsystems so the parent system
purpose may be accomplished
—  It makes necessary contributions to the parent system
—  You can’t change our system without affecting the
parent system.
—  Implications for system upgrades and modifications?
—  This gets more painful when we deal with a “system of
systems” L
And what is Systems Thinking?
—  It’s focusing on the whole system in the context of its parent system
—  It’s recognising that understanding its parts does not lead to
understanding the system
—  The system is parts AND their relationships
—  This leads to emergence
—  It’s recognising that in a system numerous loops of cause/effect/
feedback (often delayed)exist – making system behaviour often
surprising
—  It’s insisting that any “intervention” in a system be done with a
systems mindset – knowing that everything is interconnected.
—  Think early Millennium Trains problems
—  It is not an algorithmic process – it is a mind-set.
8 2/05/12 Implications? Inter Alia:
—  Elements affect each other
—  Our system affects and is affected by other systems
—  Our system is an element of larger system(s)
—  R,A,M,and S affect each other
—  RAMS and other design drivers affect each other
—  Even if we are dealing with a “purely” technical system, our
parent system may be socio-technical: human elements
—  A Dilemma:
—  So we shouldn’t make decisions in isolation, yet complexity often
compels us to!
Systems Engineering - simplistically
Key source of RAMS inputs
Reflected in
9 2/05/12 The Systems Engineering Process
—  An iterative process that entails both management and
technical activities.
—  Generally considered to comprise:
—  Requirements analysis
—  Functional analysis and allocation
—  Synthesis
—  System analysis
—  Systems Engineering Management
RAMS and Life Cycle
—  Need assessed
•  Need
—  Environment of use
determined
—  Life-spans established
•  Requirements
•  Acquisition
•  Operations/Use
•  Disposal
10 2/05/12 RAMS and Life Cycle
—  Missions etc. analysed
•  Need
—  Business process analysed
—  Operational requirements
formulated
—  Including RAMS
—  Requirements priorities
established
—  Make/buy? COTS?
—  Other constraints?
•  Requirements
•  Acquisition
•  Operations/Use
•  Disposal
RAMS and Life Cycle
—  Ideally the requirements
drive the design
—  Ideally systemic decisions
get made
—  BUT
—  Project pressures build
—  Deadlines versus
requirements – winner?
—  “Contractual” thinking can
dominate
—  Eroding Goals - ???
•  Need
•  Requirements
•  Acquisition
•  Operations/Use
•  Disposal
—  Original need?
11 2/05/12 Eroding Goals – System Archetype
RAMS and Life Cycle
—  Our source of “real world”
data
—  RAMS metrics should be
gathered
—  Are they?
—  With a view to what?
—  How are they used?
—  By whom are they used?
—  System Upgrades and
•  Need
•  Requirements
•  Acquisition
•  Operations/Use
Maintenance
—  Systems view? How?
—  Containing system(s) view?
•  Disposal
12 2/05/12 Concluding:
—  Advice to approach RAMS systemically is ubiquitous
—  Most of us accept this advice in our calmer moments
—  Many of us work hard to avoid this advice when “the going gets tough”
—  Given a set of RAMS requirements, we have sophisticated techniques of
implementation – really impressive maths and models, but…?
—  I have tried tonight emphasise the need and requirements themselves:
—  How and where do they come from? What does this imply?
—  How do they change? How should they change?
—  How do they drive our decision making?
—  I have tried to remind us that the levels of complexity demand using systems
thinking – not just advocating it
—  This means that the need and its context must be a dominant decision driver
—  Or perhaps you disagree!
Thank you.
13