powerpoint presentation and need support to help me learn.
I want to delete all the unnecessary information, for example, personal information, pics, emails , school information and logo….
Requirements: …..
www.cranfield.ac.ukMSc Systems EngineeringSystem Design and Realisation (SDR)
2MSc in Systems EngineeringUnit 06 – Introduction to Acceptance and other matters: Training, Personnel, Infrastructure, Doctrine and concepts, Organization, and InformationSession title: Introduction to conceptsAim: Provide a brief introduction to Acceptance and other mattersSystem Design and RealisationName: Tim FerrisEmail: timothy.ferris@cranfield.ac.uk
www.cranfield.ac.ukIntroduction to Acceptance
4Acceptance•The process of completing the management decision that the system is suitable to deploy for use under conditions detailed as part of the outcome of the Acceptance Process
5Acceptance•Commonly system acceptance refers to contractual acceptance of the system•That is – the system passes verification and validation tests associated with the contractual requirements•Passing the V&V tests normally triggers contract payment
6Validation process•The Validation process informs system acceptance•In validation the system is tested against stakeholder requirements•Validation yields formal evaluation of system capacity to perform its intended role•And system response under unusual circumstances (extreme environment etc)•The quality of validation of a verified system depends on the quality of transformation of the stakeholder requirements into the system requirements•Early in the development activities•Hence Conceptual Design Review is critical – this evaluates the system requirements as properly interpreting the stakeholder requirements
7Design reviews•Many design reviews identify deviations between what should-be and what is offered•Often deviations are noted•The review issues a ‘pass’ subject to certain remedial work•Emergence leads to a problem with this approach•When the remedial work is done, unless thorough tests in the context of the whole system are performed, there could be other effects so that a different deviation is introduced•I contend•If a deviation is found, then two solutions only should be considered:•Make an official compromise to accept what is offered•Rework the problem, and return for a full Design Review
8ISO/IEC 15288:2015•ISO/IEC15288:2015 does not have an Acceptance process•Implies assumption acceptance happens because•Verification determines the as-built system matches the system requirements•Validation determines the as-built system matches the stakeholder requirements•Acceptance needs further testing to determine how the system behaves in the various use-cases it could encounter
9Outcomes of Acceptance process•The outcomes of acceptance testing may be one of the following:•The system is suitable for use as planned•The system is suitable for use, but with limitations (functions permitted, use envelope, achievable performance, etc) compared with original intention•Accept the system subject to completion of changes. (This result may result in accepting limitations, or not accepting limitations)•The system is unsuitable for deployment.
www.cranfield.ac.ukIntroduction to Personnel
11Personnel•Here personnel is used to cover both MOD DLOD domains of manpower and personnel•Manpower (sic) refers to the total number of people•Personnel refers to the characteristics/attributes of the people to enable suitability for specific roles
12Attribute types•Physical attributes – weight, height, reach etc.•Classical ergonomics concerns•Skills that can be certificated•Driver’s licence•Electrician licence•The licenceshows successful completion of a training course that gives competence in a specified skill•Licencescan be ‘national’ licences, which show a person has a standard national level of skill•An organization could develop an in-house set of licencesfor distinctive in-house skills•Not needed if there is a national requirement (e.g.driving)•A technician could be nationally qualified, and in-house certified to work on specific company products
13Impact on design•Systems intended for broad markets should be designed to be used by a broad range of people•Size, strength, etc by making the human interface adjustable to suit each operator•Operating skill – if appropriate, design so that a person with a standard (national) licence qualification will be able to use it•The benefit is to minimize the training requirement and reducing the likelihood of errors during use•In some situationsaccommodating the variety of users is impractical•This adds difficulty for the organization using the asset and will add cost•Any limitation of the range of people who can use the system must be considered and justified to avoid excessive burden on the owning organisation
14Attribute types•Articulating and specifying the attributes and skills required of personnel is important to determine:•The genuine necessity of skill combinations required of personnel•The organisation recruitment and training plans and processes
www.cranfield.ac.ukIntroduction to Training
16Training•Training is the process of providing instruction, guided experience and testing achievement of requirements•Training has:•An input of people without a skill•An output of people qualified to perform a particular function
17Training•People who interact with a system need to perform their actions appropriately•They need the right skills to be able to perform their tasks•Either background resulting from national education•Good if these can be relied on for proper use of the system•Skills resulting in certificates and license for broadly defined skills•Use this either as-is for generic skills work, or as a recruitment baseline before training•Skills special to the system – can only be learned by system specific training activities•To be used where specialized and system distinctive knowledge and skills are needed•Avoid unless really necessary–expensive
18Training and education•Distinction•Training concerns learning to perform routine activities and when to apply each of several specific responses•Education concerns the development of underlying knowledge and reasoning processes•Enable facing novel challenges building on underlying principles
19Training system•Goal•To provide the right number of suitable qualified user personnel•Ensure the pipeline of trained personnel is ‘full’ to avoid shortages in supply of people•Accommodate effects of training, recruitment, and attrition of staff•Problem of skill fade must be considered –to ensure trained people are kept current
20Training system objectives•Provide the right number of people with he right skills for the task•Considerations include:•Pipeline effects – enough personnel to fill all the roles required•Ensuring attrition is addressed – during training (people who do not pass), or later depart the work (retirement, resignation, promotion to another role, illness, disablement, …)•Timeliness – so training graduates quickly move into do their tasks – avoid skill fade and frustration•Ensure trainees achieve the right combination of capabilities
www.cranfield.ac.ukIntroduction to Support Infrastructure
22Support infrastructure•A system requires support•Maintenance and logistics – Unit 5•Maintenance and logistics require means to repair/maintain, and supply•The support means can be supplied internal or external to the organisation responsible for the system
23Actions enabled by support infrastructure•Maintenance, preventive/corrective/accident, of the primary system•Supply of all parts and materials need to use the system•Shipping of the system to and from locations of use•Transport of system user and support personnel as required
24System support methods•Purchase of all support services from external suppliers.•Support services are purchased as complete services, using no in-house personnel or assets•Provision of all support activities and the support enabling systems in-house•Some combination of the above – WITH specific plans for what is provided in-house and what is purchased from external suppliers
25Issues associated with choice of support method•The criticality of the system to the interests of the owner organisation•The amount of control the owning organisation needs or wants•Issues such as priority of service•If external suppliers are used•What is the risk that when intensive support is needed your suppliers may be contractually obligated to provide higher priority service to other customers, or not have capacity to provide all the service•If internal support structures are used, the probability that necessary inputs will be available when you have high need for those inputs•Financial cost of the options•Asset holdings implications•Training implications
www.cranfield.ac.ukIntroduction to Doctrine and Concepts
27Doctrine and Concepts•Doctrine•“As a military term, Army doctrine is defined as the fundamental principles by which the military forces or elements thereof guide their actions in support of national objectives.”•Spencer, John (2016) What is Army doctrine?, Modern War Institute at West Point, https://mwi.usma.edu/what-is-army-doctrine/, (Accessed 9/10/2020)•Concepts•The idea of “concept” is defined in relation to a predicate, “Concept-of-X”.•An explanation of the ideas about how matter Xwill be addressed in the system as implemented•The doctrine and concepts terminology has specific defence origin, but the issues are relevant for all system development
28General application of the ideas•Any system will be deployed to a particular context to do something•The functions must contribute to the acquirer’s concepts of factors including maintenance, logistics, other support activities•As-is doctrine is important•When deployed the system will be in an organisation with as-is doctrine – which will influence how people try to use the system•Incidents could arise•To-be doctrine•Often systems are developed to make things different•The to-be situation needs to be well planned
29Doctrine and Concepts and requirements•Development of system requirements relies on articulation of the doctrine and concepts to be enabled by the system•Verification and validation of the system and stakeholder requirements needs the doctrine and concepts as the frame for analysis
www.cranfield.ac.ukIntroduction to Organization
31Organisation•An organization is a corporate entity that arranges people, assets and processes to achieve purpose
32Organisation•New systems usually impact the organisation by•Changing roles of people•Possibly reducing head-count with consequent effects on staff•Also, new systems either enable new functions or remove or modify previously possible functions•Some changes are accidental –not intended but resulting from the new system introduction
33Deliberate organisationalchange•Many systems deliberately make changes to organisations, with motivations:•Desire to improve productivity•To use the possibilities enabled by technology to provide service improvements•Organisational changes may arise from the primary system, or because of changes in the support systems
www.cranfield.ac.ukIntroduction to Information
35Purpose of this material•Information is used in design to:•Delineate the needs and requirements of stakeholders•Describe possible design approaches and proposals•Analyze design proposals•Information is used at transition to:•Describe the system configuration supplied•Provide instruction for use/training•Support methods and needs•Information is used through life to:•Record what has happened to the system –amount of use, conditions of use, accidents etc., maintenance and changes•Manage all these (or responses)•Digital twin –record of configuration of each instance of the system•Plan and manage system retirement
36Challenges to the systems engineering of information•Some information matters are reasonably clear•What needs to be recorded•The categories and storage form•Much information is discovered as useful to have during life – it is needed to answer a question about the system•Often data categories developed for other purposes cannot satisfy the need•The major SE challenge is to identify what categories of information should be collected to enable meaningful answers to unanticipated questions•Unanticipated questions include troubleshooting problems•Data to support defence in court cases – if they arise
37Digital Twin•Digital Twin is a current fashionable term•The concept is of a digital model of the system which enables:•A record of the current configuration of each instance of the system, use levels for each spare part fitted etc.•Record of the use life consumed, and operating conditions of each fleet member•Models to enable prediction of the effect of interactions –maintenance decision (to proceed or to leave)•This is a current area of development in the use and management of information to support the use of systems
www.cranfield.ac.ukT: +44 (0)1793 785810
www.cranfield.ac.ukMSc Systems EngineeringSystem Design and Realisation (SDR)
2MSc in Systems EngineeringUnit 2 – Analysis and Trade StudiesAim: Provide introduction to systems engineering trade-off analysesRaju was the original author of this material. Minor edits have been done here.System Design and RealisationName: Dr Raju PathmeswaranEmail: p.raju@cranfield.ac.uk
3•Systems are developed to create value for stakeholders by providing desired capabilities •When there are multiple stakeholders, there are often competing objectives and requirements •Complex system designs may offer multiple alternatives to achieve the system’s objectives, and this requires analysis to achieve the best balance among the trade-offs Trade StudyWhy it is needed
4•The process that leads to a reasoned compromise in these situations is commonly referred to as a “trade-off analysis” or a “trade study”•Trade studies aim to define, measure, and assess shareholder and stakeholder value to facilitate the decision maker’s search for an alternative that represents the best balance of competing objectives Trade StudyAim
5•Systems engineers can utilise trade-off studies to:•define the problem/opportunity•characterise the solution space•identify sources of value•identify and evaluate alternatives•identify risks•provide recommendations to stakeholders Trade Study
6•Trade Studies are a formal decision-making methodology to make choices and resolve conflicts during the systems engineering process•Trade studies identify desirable and practical alternatives at various levels: •Requirements•Technical objectives•Design•Schedule•Functional requirements •Performance requirements•Life-cycle costsAnalysis and Trade StudiesTrade Studies
7•Trade studies are defined, conducted, and documented at the various levels of the functional or physical architecture to support decision making and lead to a balanced system solution •The level of detail of any trade study needs to be appropriate with •Cost •Schedule •Performance •Risk Analysis and Trade StudiesTrade Studies
8•During early phases, trade studies are used to examine alternative system-level concepts and scenarios to help establish the system configuration•During later phases, trade studies are used to examine lower-level system segments, subsystems, and end items to assist in selecting component part designs•Performance, cost, safety, reliability, risk, and other effectiveness measures must be traded against each other and against physical characteristicsAnalysis and Trade StudiesPurposes
9Systems Engineering Process and Trade Studies
10Systems Engineering Process and Trade Studies
11Lifecycle and System DefinitionAlternative system contexts
12•System Concept Analysisrelates to the identification and selected of a SoIConcept to form the basis of the detailed SoImodelling and Stakeholder Needs elicitation•Solution Option Analysisrelates to the identification and selection of SoIOptions to form the basis of SoIfunctional modelling•System Solution Analysisrelates to the identification and selection of detailed system architecture to set a solution base line for designLifecycle and System DefinitionAlternative system contexts
13•Trade studies are required to support decisions throughout the systems engineering lifecycle•During requirements analysis, requirements are balanced against other requirements or constraints•Trade studies examine alternative performance and functional requirements to resolve conflicts and satisfy customer needsSystems Engineering Process and Trade StudiesRequirement analysis
14•Trade studies are conducted within and across functions to: •Support functional analyses and allocation of performance requirements and design constraints•Define a preferred set of performance requirements satisfying identified functional interfaces•Determine performance requirements for lower-level functions when higher-level performance and functional requirements cannot be readily resolved to the lower-level•Evaluate alternative functional architecturesDefense Acquisition University Press. “System Engineering Fundamentals.” January 2001.Trade StudiesFunctional analyses and allocation
15•During design synthesis, trade studies are used to evaluate alternative solutions to optimisecost, schedule, performance, and risk•Trade studies are conducted during synthesis to•Establish system, subsystem, and component configurations•Assist in selecting system concepts, designs, and solutions (including people, parts, and materials availability)•Support materials selection and make-or-buy decisions•Examine alternative technologies to satisfy functional or design requirements Defense Acquisition University Press. “System Engineering Fundamentals.” January 2001.Trade StudiesDesign synthesis
16•Trade studies are conducted during synthesis to•Evaluate environmental and cost impacts of materials and processes; •Evaluate alternative physical architectures to select preferred products and processes; and •Select standard components, techniques, services, and facilities that reduce system lifecycle cost and meet system effectiveness requirementsDefense Acquisition University Press. “System Engineering Fundamentals.” January 2001.Trade StudiesDesign synthesis
17•Trade studies are processes that examine viable alternatives to determine which is preferred•The trade study criteria should be identified and developed•The trade study criteria should be acceptable to all members of the team as a basis for a decision•Approach to measuring alternatives against the criteria should be agreedTrade StudiesThe process
18•If the process is followed, the trade study should produce decisions that are rational, objective, and repeatable•Trade study results should be easily communicated to customers and decision makers•If the results of a trade study are too complex to communicate with ease, it is unlikely that the process will result in timely decisionsTrade StudiesThe process
19Defense Acquisition University Press. “System Engineering Fundamentals.” January 2001.Trade StudiesThe process
20•Defining the problem involves developing a problem statement including any constraints•Bounding and understanding the problem requires identification of system requirements that apply to the study•Establishing the methodology includes choosing the mathematical method of comparison, developing and quantifying the criteria used for comparison, and determining weighting factorsTrade Study Process
21•Selecting alternative solutions requires identification of all the potential ways of solving the problem and selecting those that appear viable•Evaluating the alternatives is the analysis part of the study. It includes the development of a trade-off matrix to compare the alternativesTrade Study Process
22•System Value•Systems provide value through the capabilities they provide or the products and services they enable (Madni, 2012)•System Risks•System risks can affect performance, schedule, and costTrade-off AnalysisAims to identify
23•Decision analysis is an operations research technique that provides models to define value and an objective, mathematical foundation for trade-off analyses•The importance of opportunity definition to value creation•Chevron uses the “Eagle’s Beak”, to convey the importance of project definition and project executionSystem Value Decision analysis
24•Many of the risks create uncertainties which should be considered in trade-off analysesSystem RisksPerformance (technical)Will the product or service meet the required/desired performance?•Defining future requirements in dynamic environments•Understanding technical baseline•Technology maturity to meet performance.•Adequate modeling, simulation, test, and evaluation capabilities to predict and evaluate performance•Impact to performance from external factors (e.g., interoperating systems)•Availability of enabling systems needed to support use
25•Many trade-off studies ignore uncertainty and risk•Trade-off analysis, cost analysis, and risk analysis are usually done separately•Mustconsider performance, cost, and schedule as they are all interrelated•Performance problems can cause cost increases and schedule delays•Schedule changes can increase costsIntegrating Value and Risk Analysis
26•Why are trade studies needed?•Who should participate in a trade-off analysis?•Why is trade-off analysis different in different life cycle stages?•Should trade-off analysis be performed to support life cycle gate decisions?•Who should make the trade-off decisions?Trade StudyDiscussions
www.cranfield.ac.ukMSc Systems EngineeringSystem Design and Realisation (SDR)
2MSc in Systems EngineeringUnit 2 – Analysis and Trade StudiesAim: Provide introduction to decision management process and framework Raju was the creator of the baseline of this lectureModule 04: System Design and RealisationName: Dr Raju PathmeswaranEmail: p.raju@cranfield.ac.uk
3•Systems engineering decisions involve multiple competing objectives, numerous stakeholders, considerable uncertainty and high accountability•Discussion -Examples of •Competing objectives•Multiple stakeholders•Uncertainty•High accountabilitySystems Engineering Process
4•Decision: “A choice among alternatives that results in an allocation of resources.”•Stakeholder: “An individual or organisationhaving a right, share, claim or interest or in its possession of characteristics that meet their needs or expectations” (ISO/IEC/IEEE 15288, 2015)•Risk: “The effect of uncertainty on objectives” (ISO/IEC/IEEE 15288, 2015)•Uncertainty: “Imperfect knowledge of the outcome of some future variable.”Definitions
5•Trade-off: “Decision making actions that select from various requirements and alternative solutions on the basis of net benefit to the stakeholders” (ISO/IEC/IEEE 15288, 2015)•Trade-off Study: An engineering term for an analysis that provides insights to support system decision-making in a decision management process.Definitions
6•Value: The benefits provided by a product or service to the stakeholders (customers, consumers, operators, etc.)•Value Identification: The determination of the potential value of a new capability•Value Realisation: The delivery of the value of a new capabilityDefinitions
7•As defined by ISO 15288:2015 –•“to provide a structured, analytical framework for objectively identifying, characterisingand evaluating a set of alternatives for a decision at any point in the life cycle and select the most beneficial course of action.”Decision Management ProcessPurpose
8•The decision analysis process as described in Parnell et al. (2013) and Parnell et al. (2011) can be summarisedin 10 process steps: 1.frame decision and tailor process2.develop objectives and measures3.generate creative alternatives4.assess alternatives via deterministic analysis5.synthesiseresults6.identify uncertainty and conduct probabilistic analysis7.assess impact of uncertainty8.improve alternatives9.communicate trade-offs10.present recommendation and implementation plan. Decision Management Process
9•The center of the diagram shows the five trade space objectives (listed clockwise): Performance, Growth Potential, Schedule, Development & Procurement Costs, and Sustainment Costs .•The ten blue arrows represent the decision management process activities and the white text within the green ring represents SE process elements. •Interactions are represented by the small, dotted green or blue arrows. The decision analysis process is an iterative process.Decision Management Process
10Decision Management Process
11Process StepDescriptionFrame decisionDescribe the decision problem or opportunity that is the focus of the trade-off analysis in a particular system life cycle stageDevelop objectives and measuresUse mission and stakeholder analysis and the system artifacts in the life cycle stage (e.g., function, requirements) to define the objectives and value measures for each objective alternative needed to satisfyGenerate creative alternativesUse a divergent–convergent process to develop creative, feasible alternativesAssess alternatives via deterministic analysisUse a value model to perform deterministic analysis for trade-off analysesSynthesise resultsProvide an assessment of the value of each alternative and the cost versus value to identify the dominated alternativesIdentify uncertainty and conduct probabilistic analysisIdentify the major scenarios and system features that are uncertain and conduct probability analysisAssess impact of uncertaintyAssess the impact of the uncertainties on value and costImprove alternativesImprove the alternatives by increasing their system value and/or reducing their associated system riskCommunicate trade-offsCommunicate the trade-off analysis results to decision-makers and other stakeholdersPresent recommendations and implementation planProvide decision recommendations and an implementation plan to describe the next steps to implement the decisionDecision Management Process
12•Defining the decision opportunity is the most important step in any trade-off analysis and determines the boundary for the analysis.•The systems engineering decision process, similarly to every decision process, starts with an understanding of the problem or opportunityFrame decision
13•The mission analysis includes •stakeholder needs analysis•functional analysis•requirements analysis to identify the stakeholder needs•functions that the system must perform to create value•the requirements that must be met•the interfaces with other systems•The results of this analysis are important inputs to any trade-off analysis Stakeholder needs, functions, and requirements
14•Fundamental purpose of a system is to create value for its stakeholders•It is important to define the value in terms that are understandableby all•Term objectives include goals, criteria, and other similar terms. •An objective is specified by a verb followed by an object (noun).•Common objectives include “maximiseprofit,” “maximiseperformance,” “minimize time,” and “minimisecost.”Stakeholder objectives for the system
15•For systems engineering applications, the functional value hierarchy is a useful technique for complex systems that perform multiple functions (Parnell et al., 2011)•The functional value hierarchy has four levels: 1.System purpose2.Necessary functions and their interactions required to meet the system purpose3.Objectives for each function that defines value4.Value measures for each objective to assess the potential valueStakeholder objectives for the system
16•Developing alternatives that span the decision space is one of the most important tasks in systems engineering trade-off analyses•The decision space needs to be as large as possible to offer the most potential to create valueDecision alternatives to meet the objectives
17•The concept of morphology stems from the study of biological structures and configurations•In the 1930s, the Swiss physicist Fritz Zwicky at the Institute of Technology in California developed a problem-solving method using what he called morphological boxes, in which a new entity is developed by combining the attributes of a variety of existing entities•This method, which was initially applied by Zwicky to jet engine technology, also began to be used in marketing strategies and the development of new ideasDecision alternatives to meet the objectivesZwicky’s morphological box
18•A morphological box is a chart or table that is constructed using different dimensions that define a multivariate decision space•A morphological box provides a structure for divergent thinking that generates multiple decision alternatives•An important purpose of the trade-off analysis is to identify higher value, more affordable, and lower risk alternatives•There are three variants of the morphological box described in this section: •functional allocation box•physical architecture definition boxMorphological Box
19•Ullman (2010) describes a technique for designing with function that constructs a morphological box to create the alternatives by defining physical means for accomplishing the system’s functions•The alternatives are all possible combinations of the means for all ofthe functionsMorphological BoxFunctional allocation box
20•Source: Ullman 2010Morphological BoxMorphological box for bicycle suspension system
21•Buede(2009) employs morphological boxes to define alternatives for physical architectures•As an example, Buedeconsiders a physical device such as a hammer, which is comprised of a handle and a head, which can be further subdivided into the face, neck, cheek, and clawMorphological BoxPhysical architecture definition box
22•Source: Buede 2009Morphological BoxMorphological box used to instantiate architectures
23•https://web2.qatar.cmu.edu/~mhhammou/15390-s20/lectures/THE%20MORPHOLOGICAL%20BOX.pdf Morphological BoxFor a new car
24•Independent uncertainties •what scenario will the system be used in•how well will a technology work•what will be the cost of a new component•Dependent uncertainties•System value•Cost•ScheduleUncertaintiesThe uncertainties include
25•Considering uncertainty is especially important when systems development includes the consideration of new technologies whose cost, schedule, and value are poorly understood•System developers will typically be uncertain of all the circumstances under which users might employ the systemUncertainties
26•Technology maturity -These uncertainties can directly impact value, cost, and schedule•Requirements -Requirements can have a major impact on design features, cost, and schedule•Design features -Depending on the requirements imposed on the system and design decisions, there is uncertainty about the final design features•Adversaries -In security applications, consider the potential actions of our adversaries over time•Competition -Incommercial applications, consider the potential actions of our competitionUncertaintiesSome of the major uncertainties
27•Using decision analysis, we use our preferences to evaluate alternatives and guide the exploration•Many timesvalue measures are developed in an ad hoc fashion•Value measures should be derived from the objective identification•If stakeholders identify a value measure not linked to the objectives, it may well be that there is a missing objectiveEvaluation of alternatives
28•Systems engineering trade-off analyses need to consider finite resources•Minimisingresources required for a system is usually an objective•The primary resource is financial cost•However, other resources including manpower and facilities must be included•Three components of the resource space: people, facilities, and costsResource issues for trade-off analysis
29•Many trade-off studies do not provide an integrated assessment of value, cost, and risk(Parnell et al., 2014)•An influence diagram is used to model the relationships between decisions, uncertainties, and value and provide an integrated trade-off analysis modelFramework for integrated trade-off analyses
30•Influence diagramsare a graphical tool for mapping the interaction of the various elements of a decision setting•They usually represent decisions with rectangles; chance events or uncertainties with ovals or circles; calculated or fixed inputs and outputs with rounded rectangles, and outcomes or values with trianglesInfluence Diagrams
31Influence Diagrams
32•A firm is considering introducing a product, and its fundamental objective is to maximisethe profitExample Influence Diagram
33•A firm is considering introducing a product, and its fundamental objective is to maximisethe profitExample Influence Diagram
341.Identify the decisions to be made2.Structure fundamental-objective hierarchy and represent them as payoff and intermediate computation nodes in the influence diagram 3.Identify relevance relationships between the decision nodes and computation nodes or payoff node and draw dependence arcs to connect them 4.Identify all the uncertain eventsConstructing an Influence Diagram
355.Identify the sequence relationships between the chance nodes and decision nodes and draw corresponding arcs between them 6.Identify the relevance relationships between the chance nodes and draw corresponding arcs between them 7.Identify the relevance relationships between the chance nodes and computation nodes or payoff node and draw corresponding arcs between them 8.Check the appropriateness of the influence diagramConstructing an Influence Diagram
36Integrated trade-off value, cost, and risk analysis
37•The decisions include the functions, objectives, requirements, and system decision alternatives. •Adding the functions, objectives, and requirements asdecisions is very important, especially in the concept, architecting, and design decisions•There are several major uncertainties: stakeholder needs, scenarios, adversary actions, competition actions, technology maturity, system features, system models, value measure data, priorities, and resources Framework for integrated trade-off analyses
www.cranfield.ac.ukMSc Systems EngineeringSystem Design and Realisation (SDR)
2MSc in Systems EngineeringUnit 5 – Through life project delivery and system useSession title: Through life factorsAim: Provide a brief introduction to the through life support of systemsSystem Design and RealisationName: Tim FerrisEmail: timothy.ferris@cranfield.ac.uk
www.cranfield.ac.ukSystem Maintenance
4System maintenance•Systems must be designed in association with a specific plan for maintenance which will enable keeping the system in proper operational condition•Maintenance has three fundamental aspects:•Preventive maintenance –before failure (or alarms) on a planned basis to prevent failures occurring•Scheduled downtime•Corrective maintenance –to remediate a fault (either actual failure or alarm condition) following the occurrence of a failure•Unscheduled downtime•Accident repairs –this is a kind of corrective maintenance, but the cause is an accident•Unscheduled downtime•Likely to affect an ‘unusual’ replacement parts list
5Impact of these classes of maintenance•Preventive maintenance•Labour and materials expended while the system is still operating correctly•System shut down –appears to be a cost while the system is still usable –temptation to delay•Corrective maintenance –done when needed•Unscheduled downtime –unexpected unavailability prevents use of this system and prevents delivery of the intended service•Accident repairs•Intrusion into use –sudden loss of service•Unusual parts list results in long lead time for repair•Need to investigate extent of damage (may not be obvious)
6Levels of Repair Analysis (LORA)•Systems are generally designed to be repaired at one of three levels•Field repair•Depot repair•Supplier repair
7Field repair•OEM provides information, parts and tools•The work can be done at the site of failure (or routine service)•Repair is likely to be planned around replacement of significant assemblies which can be diagnosed easily•The assemblies are recovered to depot•Goal is to return equipment to service as quickly as possible with minimum equipment/facilities•In some casesthe plan may be for operator repair –minimal repair skills•Other repairs may be done by specialists who go to the site
8Depot repair•More complex tasks where OEM provides information, tools and parts to perform repair work•Repair work needs:•Significant time•Controlled work conditions•Specialised equipment•Maintenance personnel with specific training•Depot repair may be used for the off-line diagnosis and repair of modules/assemblies that are replaced in the field•The repaired item becomes a spare for future use•Depot repair used for system repair where difficult to fix problems have been found
9Supplier repair•More complex repairs and re-calibrations may require return to OEM for repair•Complexity of the repair task•IP issues associated with OEM providing service information•Could be commercial IP or security•Complexity/cost of equipment to do the repair work•Some suppliers use bespoke parts for which they control supply•Third party repairers cannot buy•Effect is to monopolise repair•What is available•When work is done•Pricing•May force owners into upgrade paths
10Overlay on Vee diagramElicit stakeholder maintenance needsGenerate requirementsInfluence designInclude V&V of maintenance mattersEvaluate the delivered system in actual use –consider modifying support methods or system design and modifications
11Maintenance requirements•Maintenance requirements affect the design of the primary system (the system that provides the useful service)•Maintenance requirements affect the design of the maintenance system (the system that provides maintenance for the primary system)•The inherent maintainability characteristics of the primary system and the maintenance system design combine to give an achievable set of maintainability characteristics•The consequence is the availability of the primary system
12Maintenance measures•Many measures of maintenance activity exist and can be defined (in addition to standard measures)•Mean Corrective Maintenance Time•Mean Preventive Maintenance Time•Median Active Corrective Maintenance Time•Median Active Preventive Maintenance Time•Mean Active Maintenance Time•Maximum Active Corrective Maintenance Time•Logistics Delay Time•Administrative Delay Time•Maintenance Downtime
13Maintenance measures (2)•Most of the measures are statistical measures (mean/median)•This reflects the variability of maintenance time/effort•Factors causing variability include•What has failed•Inherent difficulty of gaining access to work•Specific difficulties –such as minor damage making removing nuts/bolts difficult, etc•Difficulty diagnosing faults
14Maintenance measures (3)•More complete information about maintenance measures will provide a distribution of time required•Scheduled maintenance•Performed according to a schedule•Duration is variable, following a distribution –usually narrow variability•Corrective maintenance•Event triggered•Statistical distribution of the events can be predicted•Duration is variable, following a distribution –can be quite a wide variability
15Maintenance measures (3)•Simple measures•Occurrence and maintenance times on a ‘whole system’ basis•Useful for broad brush description of whole systems•More complex measures•Occurrence and maintenance time distributions for specific failure events –e.g.specific parts or kinds of maintenance work•Useful for managing maintenance of a specific system•Procurement and placement of spares•Capacity of repair facilities to do specific types of repair•Planning for system upgrades –if initially achieved maintainability is problematic
www.cranfield.ac.ukSystem Logistics
17Systems engineering interests in logistics•Logistics impacts various parts of the life cycle•System development•System manufacture/construction/installation•Delivery of system to customer/transport during use life•Supply of spares/materials/consumables•End of life matters
18System development•Most system development work is done in the virtual space of modelling•Some development work requires experimentation (or other empirical process)•Are all components available in reasonable buy quantities?•What is required to ship assemblies, sub-systems or the system to test sites?
19System manufacture/construction/installation•For manufactured systems•What materials and components are needed•Arrangements to ship to manufacturing site•What equipment/facilities are required to handle the inputs•When are inputs required•For constructed systems•What materials and components are needed, and when•Arrangements to ship to construction site•What equipment/facilities are required to handle the inputs•For installed systems•What assemblies and sub-systems should the system be divided into•Arrangements to ship to installation site, and when•What equipment/facilities are required to handle the inputs
20Delivery to customer/transport during use life•Means of delivery to customer•Shipping vehicles, lift tools, etc•Constraints on single item dimensions and mass•Other constraints on shipping –e.g.hazardous materials•IP and security issues associated with shipping•Transport during service life•Shipping whole system to a new base for operations•Shipping breakdown/accident damaged instances to designated repair location•Shipping supplies to site of use•Security/IP sensitivities associated with shipping (e.g.what route might a contractor take items along)
21Supply of spares/materials/consumables•System support demands supply of consumables, materials and spares for whole operational life cycle•For ‘generic’ materials and consumables –consider the specification•Are there risks of changes: environmental requirements, change of commercial product specifications, differences between countries•For COTS components –vulnerability is the decision of suppliers to continue to produce or support•Vendors changing to an ‘improved’ or ‘updated’ version –still imposes the significant cost of qualifying the replacement version in the system•For bespoke components –need to arrange for life timesupply•Either buy a lifetime supply or arrange for manufacture on demand•Life timesupply –problem to estimate the required quantity correctly –wear out, other failures and accident originated failures
22End of life matters•At end of life the system must be de-commissioned, requiring:•Means for safe/orderly final shut-down•Means to remove from site of deployment•Means to dismantle•Arrangements for disposal of the system•Shipping of the system and/or its parts to appropriate sites•Recycling of recyclable materials•Safe disposal of hazardous materials•Means to deal with sensitive information held as data –commercial IP, GDPR, national security•Means to deal with sensitive information embedded in the system itself –design configuration•Means to deal with all associated (support) systems and supplies (particularly spares in storage)
23Overlay on Vee diagramElicit stakeholder logistics needsGenerate requirementsInfluence designInclude V&V of logistics mattersEvaluate the delivered system in actual use –consider modifying support methods or system design and modifications
24Systems engineering work of logistics•Discovery of what is needed and acceptable to the stakeholders•Generating requirements for the system and its sub-systems•Establishing Verification and Validation methods•These are normally in modelling and simulation form, or observation (presence/absence of factors) because they must be conducted before the system is built (for early life cycle logistics issues) and before the through life record of actual system use and before retirement•Through use life•Observe match of expected supplies and actual supplies consumed•If there is significant deviation•Investigate cause•Propose solution and perform analysis to justify action/inaction
25Reconsider the SE and cost relationshipLife-Cycle Cost and Economic Analysis, Wolter J. Fabrycky, Benjamin S. Blanchard, Prentice Hall, 1991, ISBN: 0-13-538323-4, fig 1.5
www.cranfield.ac.ukT: +44 (0)1793 785810
www.cranfield.ac.ukMSc Systems EngineeringSystem Design and Realisation (SDR)
2MSc in Systems EngineeringUnit 04 – Through life project delivery and system useSession title: Through life factorsAim: Provide a brief introduction to the through life support of systemsSystem Design and RealisationName: Tim FerrisEmail: timothy.ferris@cranfield.ac.uk
www.cranfield.ac.ukIntroduction to Through Life Issues
4Purpose of this material•The through life phase of a system is the period through which it is used to provide its intended effect•Usually this is the longest phase of the system life cycle•Exceptions exist:•Systems with short use phases –NASA Apollo mission payloads (1960s) but:•Mission support infrastructure used repeatedly, and•Main lift elements were built as a class•Design once build many•Nuclear power stations –disposal phase is exceptionally long compared with use phase•The effectiveness of any system depends on it being designed to provide the required functions under the conditions of use and the capacity of stakeholders to support the system
5Lifecycle cost•Lifecycle cost is not directly taught in this module•All the through life issues taught contribute to the life cycle cost•Thereforeaffect the judgement of whether the system provides value to the owner•Through life cost is largely determined during the system design phase•Design determines what the system is•And all the tangible resources required to keep it in service, including:•Consumables related to use (energy, parts, materials)•Labour (especially of people who operate the system)•Maintenance –parts and materials, maintenance labour•Maintenance facilities –real estate, equipment•Logistics –to ship supplies, transport the system (if appropriate)•Means to deal with accidents and emergencies•Management and administration related to the system
6Relationship of cost and systems engineeringLife-Cycle Cost and Economic Analysis, Wolter J. Fabrycky, Benjamin S. Blanchard, Prentice Hall, 1991, ISBN: 0-13-538323-4, fig 1.5
7Relationship of cost and systems engineering (2)•Cost is determined by design•Very little can be done after engineering design decisions•Systems engineers need to explore the stakeholder needs/desires related to support•Transform the stakeholder willingness to support into requirements for the system and its elements•Then manage design to ensure implementation achieves the requirements•Through life management requires a system be in place to monitor actual consumption of inputs and use to determine if expectations are met•If not (or maybe anyway) systems engineering work through life to determine if improvements can be achieved
www.cranfield.ac.ukSystem Deployment
9Scope of System Deployment•Systems engineering work for system deployment requires discovery of the stakeholders’ concerns/interests related to:•System performance•Obvious to all parties•Less obvious (SE role to extract):•Overall duration of service•Continuity of service•Availability•Reasonable support facilities•Quantity and kinds of consumables•Quantity and kind of maintenance work•Quantity and kind (value, open market/bespoke) of spare parts•Support facilities or outsourcing approach•Needs associated with shipping the system and its supplies•Methods to deal with failures and accidents
10Outcome of SE work•Provision of system with appropriate support•Appropriate is a judgement of the responsible stakeholder•No one-size-fits-all solution•Each system requires consideration to determine what is feasible and appropriate in context
11Stages of the SE work•System concept development•Elicit the needs from relevant stakeholders•Relevant stakeholders include:•Responsible to pay for the system•Responsible to achieve and maintain certification/licencing of the system•Users (both those who use the system by management or command and those who operate the system)•Representatives of the various branches of support•Maintenance•Logistics (including managing the things and shipping)•Other stakeholders who may not have a direct input:•Those affected by the system proposal, those interacting with the system e.g.as customers (how are they to be represented?)
12Overlay on Vee diagramElicit stakeholder through-life needsGenerate requirementsInfluence designInclude V&V of through-life mattersEvaluate the delivered system in actual use –consider modifying support methods or system design and modifications
13Ulrich’s 12 questions re stakeholders1.Who ought to be the client (beneficiary) of the system S to be designed or improved?2.Who ought to be the decision taker, that is, have the power to change S’s measure of improvement?3.Who ought to be involved as designer of S?4.What kind of expertise ought to flow into the design of S, i.e., who ought to be considered an expert and what should be his (sic) role?5.Who ought to be the guarantor of S, i.e., where ought the designer seek the guarantee that his design will be implemented and will prove successful, judged by S’s measure of success (or improvement)?6.Who ought to belong to the witnesses representing the concerns of the citizens that will or might be affected by the design of S? That is to say, who among the affected ought to get involved?Ulrich, W. (1987) Critical heuristics of social systems design, European Journal of Operational Research, Vol. 31, 276-283.
14Who ought to be the client (beneficiary) of the system S to be designed or improved?•Often this is the nominal client –the buyer•Things are more complex in a professional setting•One person/group buys systems and others use them to do the organisation operations•Also, beneficiaries ripple outwards to the people who are supposed to receive the services provided by the system•These beneficiaries have different beneficial relationship•As custodian of the system usingit to provide services•As recipient of the services provided by the system•Consequentlythere are different measures of success for different stakeholders
15Who ought to be the client (beneficiary) of the system S to be designed or improved? (2 cont.)•These stakeholders are likely focused on what the system should do for them (when it is working properly)•There are different measures of success for different stakeholders•These stakeholders are likely focused on what the system should do for them (when it is working properly)
16Who ought to be the decision taker, that is, have the power to change S’s measure of improvement?•This is the stakeholder who makes decisions about what the system should be and how it should perform•This stakeholder is likely focused on Return on Investment (in either or both the physical domain and financial domain)
17Who ought to be involved as designer of S?•In engineered systems the technical design is allocated to engineers with appropriate technical knowledge•Very interesting design issues precede that•Who ought to be involved in the system level design of:•What the system input and output relationships should be?•What possibilities should be enabled or supported by the system?•What possibilities should be precluded by the system?
18What kind of expertise ought to flow into the design of S, i.e., who ought to be considered an expert and what should be his (sic) role?•For the technologythe answer depends on the technology to be applied in the systemBUT•The purpose of the system has something to do with a human purpose to achieve some kind of outcome in the world in order tofurther a human motivation•Who is appropriate to design means to achieve this outcome•What expertise is needed to design stuff which will enable achievement of the intended purpose without unexpected consequences
19Who ought to be the guarantor of S, i.e., where ought the designer seek the guarantee that the design will be implemented and will prove successful, judged by S’s measure of success (or improvement)?•This question has to do with how and by whom the V&V work should be done•Issues include:•Does the nominated party have the necessary expertise•Does the nominated party have the capacity, willingness and intent to avoid bias•Is there any conflict of interest that may make a material impact on the judgement or give the appearance of possible biasUlrich, W. (1987) Critical heuristics of social systems design, European Journal of Operational Research, Vol. 31, 276-283.
20Who ought to belong to the witnesses representing the concerns of the citizens that will or might be affected by the design of S? That is to say, who among the affected ought to get involved?•This question is particularly pertinent to the through-life question•Who will be using the system as a manager/commander•i.e.the system is used as a tool to effecttheir purpose/intent in a broader environment•Who will be using the system hands-on?•This party is concerned with Human Factors issues (physical and mental) related to being able to properly, safely and effectively do their tasksUlrich, W. (1987) Critical heuristics of social systems design, European Journal of Operational Research, Vol. 31, 276-283.
21What do we ask the stakeholders•What do we need to know to enable decisions about through life issues1.What ought to be the purpose of S, i.e., what goal states ought S be able to achieve so as to serve the client?2.What ought to be S’s measure of success (or improvement)?3.What components (resources and constraints) of S ought to be controlled by the decision taker?4.What resources and conditions ought to be part of S’s environment, i.e., should not be controlled by S’s decision taker?5.Upon what world-views of either the involved or affected ought S’s design be based?
22What ought to be the purpose of S, i.e., what goal states ought S be able to achieve so as to serve the client?•This requires questions about the functions, performance levels and conditions of operation•Clarity is needed whether those are ‘normal conditions’ characteristics or include the extremes•Is the space delineated in the performance/conditionsenvelope ‘all extremes simultaneously’ or is there some tapering of the requirement for one at extreme points of another
23What ought to be S’s measure of success (or improvement)?•Easy to think of this as a static, ideal conditions, success/improvement•Clarity is needed re the impact of challenging conditions•Is the success/improvement specifically related to challenging conditions response•How is the success/improvement manifest in through-life outcomes
24What components (resources and constraints) of S ought to be controlled by the decision taker?•This concerns the system boundary•Specifically, what elements of the system will be included in the system under management of the key leader•For example –how much of the supply chain for required resources is under the direct management of the organisation responsible for the primary delivery system•Is the system under development/modification required to fit in with existing assets and infrastructure of the owner?
25What resources and conditions ought to be part of S’s environment, i.e., should not be controlled by S’s decision taker?•This is the converse of previous question•What resources and surrounding things are to be assumed to be present in the environment•This would identify where it is assumed that inputs will be obtained through normal market means
26Upon what world-views of either the involved or affected ought S’s design be based?•The through-life issues here concern the extent to which the owner should be capable of operating independently of other inputs•There are also function and performance issues concerned with matters such as the distribution of work and responsibility to particular people within, or interacting with, the system
27Verification and Validation process•The V&V process for the system must include V&V of all requirements, including those affecting through life issues•For most through-life requirements it is impractical to perform V&V by direct experimentation•Many through-life characteristics become evident through time intervals approaching the intended practical life of the system•Accelerated aging methods exist for certain phenomena but the different physics and chemistry scaling factors make accelerated aging of a whole system impractical•The time required (even with accelerated aging) is likely to be a substantial proportion of the intended life –making repeated aging testing (to test design iterations) impractical•Many through-life characteristics are described as probabilities of events –impractical for small quantity testing
28V&V approach•Most through-life V&V must use analysis based on the known characteristics of particular relevantphenomena and the design configuration•Risk:•The analysis is based on design assumptions of:•Arrangement of elements•Loads imposed on elements in operation•Operational environment•Intensity of use•May not accurately incorporate the combination of all extreme points for each tolerance –leaving gaps in the operational envelop that is analysed
29Impact of V&V limitations•The result is:•The system, even used in the planned environment with the designed usage may wear differently than expected•The system may be used with different intensity or in a different environment•Consumption of resources: operational supplies, spares, maintenance, accident recovery, shipping, … may differ from expectations•During life consumption of resources must be monitored and compared with design expectations•Deviations must be investigated to get explanation•After explanation deviations must be judged as:•‘To be accepted, modify the expected inputs’•‘Seek modification’ to yield improved resource use•The modification may be of use profile or system configuration
30Systems engineering in through-life phase•Systems engineering tasks in through-life phase•Planning what to monitor and the method of recording information to make it usable in various kinds of investigation•The challenge is we do not know what questions we will investigate later, but data can only be collected when events happen•Proposing potential changes in system use or configuration and modelling potential impact•Developing formal proposals resulting from hypothesised configurations•Managing the process of system (or system use) modification
www.cranfield.ac.ukSystem Operation
32Systems engineering for system operation•The purpose of the system is realised in its operation•Fundamental issues are:•What must the system do?•Functions•How well must it do those functions?•Performance parameters•Where must it perform?•Environment factors and supply chain implications•When must it perform?•The amount of use and other details of use profile•Why will the system be used?•This points to constraint issues•Who will use and interact with the system?•Leads to Human Factors and organisational issues
33Overlay on Vee diagramElicit stakeholder system use needsGenerate requirementsInfluence designInclude V&V of system use mattersEvaluate the delivered system in actual use –consider modifying support methods or system design and modifications
34What must the system do?•This is an obvious front-of-mind issue•All consideration of a system should be based on its purpose•Often other aspects of the dream around the system acquisition become confused•Common problems include•I want to replace the existing solution with something essentially the same•Perhaps without determining that replacement is the best solution•Political announcements that generate community expectation for a particular solution without well-reasoned purpose•Presentation of a project dream with disparate and often conflicting objectives•Not articulating the real purpose of a project –resulting in attempting to build a solution to a different problem
35How well must it do those functions?•Bespoke developments are done so rarely that the initial desire is for a major jump on previous performance levels•This leads to ‘grand dream’ intended performance parameters•Often with little understanding of the technical implications•Often the people involved do not have expertise in the technology•So do not know what is realistic or the cost implications
36How well must it do those functions?•General rules of thumb:•Conservative performance levels can be provided by more mature technologies•Mature technologies have track record•Cheaper, known performance, known limitations and support implications•Novel technologies•More development cost, less knowledge about performance, limitations, support•Achievable thresholds for technologies are not ‘nice round numbers’ (even if the common name includes a round number)
37How well must it do those functions?•The rarity of bespoke development may lead to ambitious ‘round number’ specification•Real knowledge is needed to wisely specify required performance levels•Implications of inappropriate performance level specification•Excessive development cost•Excessive support cost•Reliability problems leading to excessive out of service•Higher support costs: repairs, replacement parts, where maintenance can be done (more later) leading to higher cost•The impact includes:•Reduced system availability•Reduced user confidence in the system•Reduced overall effectiveness
38Where must it perform?•The use environment determines the conditions under which the system must provide its performance•It must be designed to work correctly in the environment where it is to be used•The obvious issue is the physical environment –temperature, humidity, dust, …•Regulatory environment is essential for the system to be legal to use in each jurisdiction where it may be used•Infrastructure which can be assumed available for support•Support ‘preferences’ in different markets•e.g.different relativity of cost/availability of labour, parts and materials•What conditions will the system be subject to in shipping and storage (if applicable)
39Where must it perform?•Effect of these issues:•Stresses and degradations the system is exposed to•Affects wear and tear on the system•Limits choice of methods, technologies and materials•May affect achievable performance for particular capacityof equipment items•Version control issues•Particularly commercial products intended for multiple markets•Regulations and physical environment may demand different system configurations differentiated by market•Manufacturer support issues –parts, information, advice•Consequent limitations for customers to use the system in different locations, limiting second-hand markets
40When must it perform?•This has many aspects•The total life-cycle interval –when will it be put in service and retired•This determines the required durability•Support needs must be provided for the whole of life•Skills, support equipment, training, spares, consumables, etc•Duration of episodes of use, downtime during which re-supply and maintenance can be done•Regularity of use cycles•Assets used infrequently often have problems with degradation related to elapse of time –possibly making them unusable when needed (and alsoas a total life cycle problem)•Assets used ‘continuously’ may wear better because they are always in a normal operating condition
41Why will the system be used?•This is another way into determining what functions are required•The reason for use indicates what users will be attempting to use the system to do•Enables preparing use cases to elucidate those events/conditions•Also provides insight into what assumptions can be made about available infrastructure•Systems to be used in ‘normal’ times can assume the provision of ‘normal’ affordances of infrastructure•Systems to be used in stressed locations or times need to be designed assuming absence of ‘normal’ affordances•Thereforethe system design and boundaries need cognisance of what can be assumed to be available
42Who will use and interact with the system?•Characteristics of people include:•Physical –size, strength, etc.•Leads to traditional ergonomics design impact•Intellectual –knowledge•What background knowledge can be assumed?•Training needs to enable proper use of the system•What assumptions can be made about other people who will interact with the system•Will they need training of any kind? Is it practical to train them?•Organisational issues•Does the system fit with (or change) existing organisational relationships and responsibilities?•Does the acquiring organisation understand the implications of any change?
43Requirements generation•Answers to these questions enable determination of system requirements related to use•The first stage of validation requires evaluation of the requirements with the buyer (party commissioning the development)•These inform design
www.cranfield.ac.ukT: +44 (0)1793 785810
www.cranfield.ac.ukMSc Systems EngineeringSystem Design and Realisation (SDR)
2MSc in Systems EngineeringUnit 5 – Through life project delivery and system useSession title: Through life factorsAim: Provide a brief introduction to the through life support of systemsSystem Design and RealisationName: Tim FerrisEmail: timothy.ferris@cranfield.ac.uk
www.cranfield.ac.ukSystem Maintenance
4System maintenance•Systems must be designed in association with a specific plan for maintenance which will enable keeping the system in proper operational condition•Maintenance has three fundamental aspects:•Preventive maintenance –before failure (or alarms) on a planned basis to prevent failures occurring•Scheduled downtime•Corrective maintenance –to remediate a fault (either actual failure or alarm condition) following the occurrence of a failure•Unscheduled downtime•Accident repairs –this is a kind of corrective maintenance, but the cause is an accident•Unscheduled downtime•Likely to affect an ‘unusual’ replacement parts list
5Impact of these classes of maintenance•Preventive maintenance•Labour and materials expended while the system is still operating correctly•System shut down –appears to be a cost while the system is still usable –temptation to delay•Corrective maintenance –done when needed•Unscheduled downtime –unexpected unavailability prevents use of this system and prevents delivery of the intended service•Accident repairs•Intrusion into use –sudden loss of service•Unusual parts list results in long lead time for repair•Need to investigate extent of damage (may not be obvious)
6Levels of Repair Analysis (LORA)•Systems are generally designed to be repaired at one of three levels•Field repair•Depot repair•Supplier repair
7Field repair•OEM provides information, parts and tools•The work can be done at the site of failure (or routine service)•Repair is likely to be planned around replacement of significant assemblies which can be diagnosed easily•The assemblies are recovered to depot•Goal is to return equipment to service as quickly as possible with minimum equipment/facilities•In some casesthe plan may be for operator repair –minimal repair skills•Other repairs may be done by specialists who go to the site
8Depot repair•More complex tasks where OEM provides information, tools and parts to perform repair work•Repair work needs:•Significant time•Controlled work conditions•Specialised equipment•Maintenance personnel with specific training•Depot repair may be used for the off-line diagnosis and repair of modules/assemblies that are replaced in the field•The repaired item becomes a spare for future use•Depot repair used for system repair where difficult to fix problems have been found
9Supplier repair•More complex repairs and re-calibrations may require return to OEM for repair•Complexity of the repair task•IP issues associated with OEM providing service information•Could be commercial IP or security•Complexity/cost of equipment to do the repair work•Some suppliers use bespoke parts for which they control supply•Third party repairers cannot buy•Effect is to monopolise repair•What is available•When work is done•Pricing•May force owners into upgrade paths
10Overlay on Vee diagramElicit stakeholder maintenance needsGenerate requirementsInfluence designInclude V&V of maintenance mattersEvaluate the delivered system in actual use –consider modifying support methods or system design and modifications
11Maintenance requirements•Maintenance requirements affect the design of the primary system (the system that provides the useful service)•Maintenance requirements affect the design of the maintenance system (the system that provides maintenance for the primary system)•The inherent maintainability characteristics of the primary system and the maintenance system design combine to give an achievable set of maintainability characteristics•The consequence is the availability of the primary system
12Maintenance measures•Many measures of maintenance activity exist and can be defined (in addition to standard measures)•Mean Corrective Maintenance Time•Mean Preventive Maintenance Time•Median Active Corrective Maintenance Time•Median Active Preventive Maintenance Time•Mean Active Maintenance Time•Maximum Active Corrective Maintenance Time•Logistics Delay Time•Administrative Delay Time•Maintenance Downtime
13Maintenance measures (2)•Most of the measures are statistical measures (mean/median)•This reflects the variability of maintenance time/effort•Factors causing variability include•What has failed•Inherent difficulty of gaining access to work•Specific difficulties –such as minor damage making removing nuts/bolts difficult, etc•Difficulty diagnosing faults
14Maintenance measures (3)•More complete information about maintenance measures will provide a distribution of time required•Scheduled maintenance•Performed according to a schedule•Duration is variable, following a distribution –usually narrow variability•Corrective maintenance•Event triggered•Statistical distribution of the events can be predicted•Duration is variable, following a distribution –can be quite a wide variability
15Maintenance measures (3)•Simple measures•Occurrence and maintenance times on a ‘whole system’ basis•Useful for broad brush description of whole systems•More complex measures•Occurrence and maintenance time distributions for specific failure events –e.g.specific parts or kinds of maintenance work•Useful for managing maintenance of a specific system•Procurement and placement of spares•Capacity of repair facilities to do specific types of repair•Planning for system upgrades –if initially achieved maintainability is problematic
www.cranfield.ac.ukSystem Logistics
17Systems engineering interests in logistics•Logistics impacts various parts of the life cycle•System development•System manufacture/construction/installation•Delivery of system to customer/transport during use life•Supply of spares/materials/consumables•End of life matters
18System development•Most system development work is done in the virtual space of modelling•Some development work requires experimentation (or other empirical process)•Are all components available in reasonable buy quantities?•What is required to ship assemblies, sub-systems or the system to test sites?
19System manufacture/construction/installation•For manufactured systems•What materials and components are needed•Arrangements to ship to manufacturing site•What equipment/facilities are required to handle the inputs•When are inputs required•For constructed systems•What materials and components are needed, and when•Arrangements to ship to construction site•What equipment/facilities are required to handle the inputs•For installed systems•What assemblies and sub-systems should the system be divided into•Arrangements to ship to installation site, and when•What equipment/facilities are required to handle the inputs
20Delivery to customer/transport during use life•Means of delivery to customer•Shipping vehicles, lift tools, etc•Constraints on single item dimensions and mass•Other constraints on shipping –e.g.hazardous materials•IP and security issues associated with shipping•Transport during service life•Shipping whole system to a new base for operations•Shipping breakdown/accident damaged instances to designated repair location•Shipping supplies to site of use•Security/IP sensitivities associated with shipping (e.g.what route might a contractor take items along)
21Supply of spares/materials/consumables•System support demands supply of consumables, materials and spares for whole operational life cycle•For ‘generic’ materials and consumables –consider the specification•Are there risks of changes: environmental requirements, change of commercial product specifications, differences between countries•For COTS components –vulnerability is the decision of suppliers to continue to produce or support•Vendors changing to an ‘improved’ or ‘updated’ version –still imposes the significant cost of qualifying the replacement version in the system•For bespoke components –need to arrange for life timesupply•Either buy a lifetime supply or arrange for manufacture on demand•Life timesupply –problem to estimate the required quantity correctly –wear out, other failures and accident originated failures
22End of life matters•At end of life the system must be de-commissioned, requiring:•Means for safe/orderly final shut-down•Means to remove from site of deployment•Means to dismantle•Arrangements for disposal of the system•Shipping of the system and/or its parts to appropriate sites•Recycling of recyclable materials•Safe disposal of hazardous materials•Means to deal with sensitive information held as data –commercial IP, GDPR, national security•Means to deal with sensitive information embedded in the system itself –design configuration•Means to deal with all associated (support) systems and supplies (particularly spares in storage)
23Overlay on Vee diagramElicit stakeholder logistics needsGenerate requirementsInfluence designInclude V&V of logistics mattersEvaluate the delivered system in actual use –consider modifying support methods or system design and modifications
24Systems engineering work of logistics•Discovery of what is needed and acceptable to the stakeholders•Generating requirements for the system and its sub-systems•Establishing Verification and Validation methods•These are normally in modelling and simulation form, or observation (presence/absence of factors) because they must be conducted before the system is built (for early life cycle logistics issues) and before the through life record of actual system use and before retirement•Through use life•Observe match of expected supplies and actual supplies consumed•If there is significant deviation•Investigate cause•Propose solution and perform analysis to justify action/inaction
25Reconsider the SE and cost relationshipLife-Cycle Cost and Economic Analysis, Wolter J. Fabrycky, Benjamin S. Blanchard, Prentice Hall, 1991, ISBN: 0-13-538323-4, fig 1.5
www.cranfield.ac.ukT: +44 (0)1793 785810