Introduction
Perhaps the number 1 mistake we at PHMT observe in engineers approaching modelling in MADe for the first time is wading into modelling activities without considering why they are modelling in the first place. Creating items, assigning functions and flows, building failure diagrams and filling out every data field that is come across. This will prove to be a waste of time with the end result a cumbersome, low quality model.
The intent here is not to scare people away from playing around in MADe, cracking into a model is generally fine for getting used to the mechanics of model building, but when addressing a model in a serious context some forethought and planning goes a long way.
Scoping out the expectations of a project within MADe prior to commencing modelling is an essential step to target modelling efforts so that:
a. Time is not wasted in completing models and entering data that will not be used
b. Early modelling is cognisant of later goals and early models remain applicable for later analysis
Models in MADe
In the broad scope of engineering analyses there are endless varieties of models and selecting which to use is dependent on what is required of the model. Any given model cannot always do any given task. Recognizing this is deeply relevant to modelling success in MADe. MADe as a model-based engineering analysis tool is primarily aimed at safety, reliability, maintenance, and diagnostic design. But within MADe there is not one singular model that caters for all the analyses that MADe is capable of aiding with or completing. MADe as a platform for complex analyses inherently requires multiple perspectives of modelling. The challenge being integrating the constraints and requirements of each analysis underneath a unified platform to structure the common data and system representations.
It can be more helpful to think of MADe as a series of highly interrelated and interconnected models with large areas of commonality and data. An example of these interconnected models is the functional diagram in which high level system functions are devolved to specific functional requirements for the purpose of Functional Hazard Analysis (FHA). This functional diagram shares and informs functions and system failures with the logical system model (the functional flow based model that most people would consider ‘the MADe model’) where functions of items are interconnected and failures can be propagated. Failures are propagated through one of two simulation methods, FCM or Bond, each of which also has an underlying model that is embedded and integrated within the logical system model but are distinct from it. Reliability analyses are handled by the RBD, a model that is an alternate perspective of the logical system model, sharing with it hierarchy and items but not functional connection. That is just an example of the types of models in MADe and how they interact.
Taking this principle of shared data within interlinked models underneath a common software platform. The advantages being a natural division of model development and analysis responsibility
based on typical engineering roles whilst leveraging cross-domain commonality of information. Accountability is maintained at the same time as efficiency and data extensibility is improved.
An Approach to Planning in Response to Project Needs
As mentioned previously the main benefits of planning modelling activities is to avoid wasted time on irrelevant modelling and ensure models are extensible for later use.
Expanding on the second point, orders of operation of modelling and analysis can often be based on convenience and availability of data and project resource. This represents a non-optimal approach as data commonality and extensibility is not the driving consideration leading to inefficient work and engineers across roles re-collecting data and re-conducting baseline work that underpins multiple analytical outputs.
In general the main guiding principle in determining order of analysis is to address tasks that are required for multiple applications first (for example establishing system/model hierarchy, determining operational context and assumed missions, sourcing reliability data) and leaving singular analysis outputs on a secondary basis (for example development of maintenance actions, production of a reliability report).
Planning for modelling does not require anything wildly outside a standard planning process (as represented below), what we are trying to achieve is an actionable modelling approach from devolving general project goals.
1. Goal of Project – the overall goal of the project, including reasoning behind the usage of a model-based engineering solution.
2. Deliverables – the outputs that will be used in improving a design and meeting the goals stated. Often in context of applicable regulations and standards as a key consideration.
3. Analyses Required to Support Deliverables – the analyses that are used (potentially in combination) to produce the needed outputs
4. Modelling Approach – The type of modelling required and the detail to which to apply it
5. Pre-requisite System Knowledge and Data – the data that will be used to fill the model and the knowledge of the system the user requires to correctly model
6. Development of Process – Process that will be followed to create the model and produce the deliverables
This is a general process to follow in order to help define and align stakeholders’ goals and the work required in and supplemental to a modelling platform. As outlined in the process flow above the initial steps taken when preparing for a project are aimed at establishing the outcomes required of the project. With these outcomes identified the data, theoretical knowledge, modelling approach and analyses can be determined as a result.
A secondary step in forming the goals of the project and use of the modelling software, after deciding on the user role, is clarifying outcomes. These outcomes are overarching statements aimed at succinctly summarizing the purpose of using a model-based platform in the context of the project.
This selection of outcomes will further help with understanding the outputs and analyses that will need to be conducted in the project.
· The combination of user types and outcomes selected in the previous step should clarify the general purpose of and usage case for the software
· From this position the outputs that will support the overall goals of the project will be determined
· In this context an output is a piece of documentation generated by the modelling platform to support decision making and verify a requirement or lead to actionable changes to the project or product and importantly make sense outside of the context of the modelling software. For example, a FMECA report for the product does not need to be read through the lens of someone proficient in model-based engineering.
· Many engineering projects will have adherence to standards that are tied to specific outputs. As such these standards are a consideration when picking outputs
Although similar to outputs/deliverables, analyses are the software driven processes that can be conducted within a modelling platform. An analysis is often a pathway to an output. In this sense an output may have several analyses that can lead to it. The selection of the most appropriate analysis (or pathway) should be made depending on the context of the project and the information available to the accountable engineer. For example, a required output of the project may be maintenance costings, depending on stage of the design this may be achieved by conducting a course cost estimation analysis or via creation of detailed maintenance actions in a Reliability Centered Maintenance (RCM) analysis. Determining appropriate analyses for the project is driven by the combination of project goals, deliverables, and personnel.
Where does this get you?
The outcome of the planning and project definition process is a project plan. This can be mapped out in a multitude of ways but the key points that need covering are:
1. What are the main tasks?
2. What are the main roles / clusters of work?
3. What order should the tasks be conducted in?
If you have these answered you are ready to model!
A convenient way to map out these is as presented below, featuring streamlines of clusters opposed with a rough order of operation based on building model structure and general data population first through to analysis and verification last.
