RAMS, Systems Engineering and Systems Thinking

Transcription

1 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 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

3 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

4 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 lifecycle; 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

5 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

6 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,

7 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

8 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

9 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

10 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 Environment of use determined Life-spans established Need Requirements Acquisition Operations/Use Disposal 10

11 RAMS and Life Cycle Missions etc. analysed Business process analysed Operational requirements formulated Including RAMS Requirements priorities established Make/buy? COTS? Other constraints? Need 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 -??? Original need? Need Requirements Acquisition Operations/Use Disposal 11

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 Maintenance Systems view? How? Containing system(s) view? Need Requirements Acquisition Operations/Use Disposal 12

13 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