CONFERENCE HANDBOOK
Model-Based Systems Engineering Symposium Innovate, represent and communicate in conceptual design An event of the Australian Systems Engineering Workshop 2013 11- 12 NOVEMBER 2013, MAWSON LAKES, SA
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
Contents Keynote speaker
2
Program 3 Symposium Dinner
5
General information
5
Speakers’ information and abstracts 1
George Strengers
6
2
Daniel Spencer
7
3
Michael Kretzenbacher, Ross Findlay, Caroline Lange & Dr Wenyi Yan
11
4
Meredith Hue
20
5
Michael Waite
21
6
Jack Ring
24
7
Despina Tramoundanis & Major Timothy Walmsley
25
8
Matthew Hause & Lars-Olaf Kihlstrom
28
9
Pin Chen & Mark Unewisse
31
10
Stephen Passmore & Alan Smeaton
33
11
Nicola Broderick, Michael Waite & Matthew Tetlow
36
12
Quoc Do & Stephen Cook
38
13
Frank Lui, Michael Harris & Stephen Passmore
40
14
Amelia Eggerking & Wayne Power
42
Workshops 1
George Strengers
46
2
Michele Knight & Les Vencel
47
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
2
Keynote speaker
Dr John Riley Born in Adelaide South Australia, Dr John Riley studied at the Flinders University of South Australia where he obtained a PhD in Atomic Physics in 1985. After completing an Australian Research Grants Scheme (ARGS) research fellowship in the same field in late 1985 he joined private industry as an applications physicist working in the development of instrumentation for the mining industry. Dr Riley joined the Defence Science and Technology Organisation (DSTO) in July 1988 working in the area of sonar signal processing. This work focused on the development of novel techniques to improve the capabilities of existing submarine and surface ship towed array systems and airborne sonobuoy systems. Dr Riley was awarded a DSTO Defence Science Fellowship to work at the Defence Research Establishment Atlantic (DREA) in Nova Scotia Canada in 1993 and 1994. Some novel work, which had its origins during this attachment, on the development of low frequency multistatic sonobuoy systems, was recognised with the award of the AMRL Best Research award to the “Bistatic Barra” team in 1996. Dr Riley was appointed to the position of Navy Scientific Adviser in 1997. After a further stint back in DSTO Edinburgh as the Head of Airborne Sonar in 1998 and 1999 he was appointed to a position
in the Australian Embassy in Washington DC as the Defence Science Attaché with responsibility for liaison with the USA and Canada across a wide spectrum of technology areas. Twelve months into this posting Dr Riley was promoted to the position of Research Leader Submarine Operations and was transferred back to Australia to lead DSTO’s site at HMAS Stirling in Western Australia. This position had responsibility for the S&T programs supporting both the submarine combat systems replacement program as well as for the evolution of the submarine sonar systems. In August 2001, Dr Riley was transferred back to DSTO in Edinburgh, South Australia to take a broader leadership role as the Research Leader Maritime Combat Systems and a role in coordinating DSTO’s support for surface combatants. In this role he was responsible for both submarine and surface ship combat system R&D programs including acting as the S&T Adviser for the Air Warfare Destroyer project. In January 2006, he was appointed Chief Maritime Operations Division. In this role Dr Riley has responsibility for a wide range of Maritime focused S&T programs as well as responsibility for staff at three sites; DSTO WA, DSTO Sydney and DSTO Edinburgh. As lead Chief for the major maritime acquisition projects including the Future Submarine, Future Surface Combatant and the Offshore Combatant Vessel he has direct oversight of the S&T programs supporting these major projects. He has also recently completed his 3 year term as the Executive Chair of the Maritime Systems Group of TTCP. In July 2013, he was appointed as the Chief of Weapons and Countermeasures Division and has responsibility for a wide ranging S&T program supporting Defence’s weapons acquisition and sustainment programs as well as a forward looking program in future weapons technologies.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
3
Program Monday, 11 November 2013 Time
#
Title
Presenter/s
08:30
Registration open
09:00
Welcome and administration
Kevin Robinson
09:10
SESA Welcome
Shaun Wilson SESA President-Elect
09:30
Keynote - Dr John Riley
Dr John Riley Chief of Weapons & Countermeasures Division, DSTO
A structured approach to model-based concept development
George Strengers BAE Systems
10:00
1
10:30
Refreshments
11:00
2
Model-based capability in fire and emergency services
Daniel Spencer Aerospace Concepts Pty Ltd
11:30
3
An assessment of Model-Based Systems Engineering (MBSE) through the SysML modelling of the Mascot Asteroid Lander system
Michael Kretzenbacher Monash University
12:00
Lunch
12:45
4
MBSE - Navigating mindsets and perspectives
Meredith Hue DSTO
13:15
5
The challenge of review in a model-based world
Michael Waite Aerospace Concepts Pty Ltd
13:45
Refreshments
14:15
Workshops (parallel stream) Workshop 1: Structured approach to concept development
George Strengers BAE Systems
Workshop 2: How can MBSE capture user perspectives of complex capability needs?
Michele Knight, DSTO Les Vencel, VCORP Consulting Pty Ltd
16:15
Workshop summary presentations and discussion
17:00
Day 1 close
18:30
Symposium Dinner Adelaide Entertainment Centre Pre-dinner drinks followed by dinner at 19:00
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
4
Program Tuesday, 12 November 2013 Time
#
Title
Presenter/s
Morning coffee 09:00
Update from INCOSE
David Long INCOSE President-Elect
09:30
6
The problematic situation (streamed from o/s)
Jack Ring Educe LLC
10:00
7
Model based conceptual design: Integration of analysis requirements into the WSAF schema
Despina Tramoundanis DSTO Major Timothy Walmsley Australian Army
10:30
Refreshments
11:00
8
“All for the want of a horseshoe nail”: An examination of causality in DoDAF (streamed from o/s)
Matthew Hause Atego Lars-Olaf Kihlstrom Syntell AB
11:30
9
Modelling and management of relationships between military SoS
Dr Pin Chen & Dr Mark Unewisse DSTO
12:00
10
Modelling an Expeditionary Airbase Capability system
Stephen Passmore DSTO Alan Smeaton Clarity Concepts Pty Ltd
Lunch
12:30 13:15
11
Model-Based Systems Engineering for capability enhancement of systems of systems
Nicola Broderick DSTO Michael Waite & Matthew Tetlow Aerospace Concepts Pty Ltd
13:45
12
A study of a model-centric practice across the acquisition boundary
Quoc Do DASI, UniSA Stephen Cook UniSA
14:15
Refreshments
14:45
13
Analysis of military systems using a model-based methodology
Frank Lui, Michael Harris & Stephen Passmore DSTO
15:15
14
Application of MBSE tools and techniques to elicit and analyse weapon system modelling, simulation and analysis requirements
Amelia Eggerking & Wayne Power DSTO
15:45
Closing remarks
Kevin Robinson
16:00
Day 2 close
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
5
Symposium Dinner
General Information
Monday, 11 November 2013 The Conference Dinner will be held at the Adelaide Entertainment Centre, 98 Port Road, Hindmarsh and will include a three course meal and beverages, pre dinner drinks commence at 1830. The cost of the food, and beverages is included in the full registration.
Banking An ATM is available on the ground floor of the Mawson Lakes Hotel. Catering Morning tea, lunch and afternoon tea are included in the registration fee, and will be served in the pre function area to the Conference rooms. Dietary and mobility needs If you have pre booked a special meal or require any mobility assistance, please check with the registration desk for directions. Pre booked special meals will be available by asking the venue supervisor at the time. Registration desk and check-in The meeting registration desk will be situated in foyer on Level 1 of the Mawson Lakes Hotel. It will be open for registration and enquiries at the following times: Monday, 11 November, 08:30 - 17:00 Tuesday, 12 November, 08:30 - 15:00
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
6
Speakers’ information and abstracts
PLEASE NOTE: More detail on this paper is included as Appendix 1.
1. A structured approach to model-based concept development George Strengers BAE Systems
Model-based systems engineering methods will realize and require a structured approach to the Concept Development phase of a project or system lifecycle. A model-based environment must capture and develop a diverse range of concept knowledge. Such knowledge may arise from established sources but models must also induct creative and innovative measures adopted during concept exploration. Model Based Concept Development (MBCD) environments will typically have to deal with a plethora of tools and knowledge sources. Concept Development shared across Acquirers and Suppliers must also be accommodated where in some situations models may be shared but in other situations the inability to share models must be dealt with expeditiously. Short time frames due to pressures of time-tomarket or time-to-bid drive brevity of MBCD modelling activity. Thus Concept Intervention System models and Concept Realization System models are by necessity concise and focused on the need to elicit understanding of system scope, costs and risks. whereas fuller development of Intervention System models and Realization System models will occur in later stages of system design. Concept models must address both technical and business aspects of a concept to ensure that a balanced approach is taken to truly
assessing the likelihood of concept success. A balanced approach is obtained by developing Organisational Models which focus on the motivations within the problem space as well as more traditional modelling areas of Operational Models and System Models in order to form views of the problem space and the solution space. MBCD Organisational, Operational, Systems modelling methods must develop Concept Intervention System models and Concept Realization System models that both embody and elicit Stakeholder Needs and System Requirements. The models must facilitate linkages between requirements and stakeholder needs so as to validate the needs. The models must support development of subsystem requirements partitioned in a manner that supports effective system development and acquisition. MBCD models must support definition of Realization Systems in terms of the processes and system requirements needed in order to develop and acquire an Intervention System. All of this modelling may need to be repeated to yield a multiplicity of Candidate Concepts. MBCD will foster efficient tool – based assessment of Concept Strength. Tool-based metrics and comparisons of Concept Strength will allow early elimination of weak concepts and allow efficient down-selection to an Agreed Candidate Concept. Concept Assurance is an important part of the governance of a Concept Development phase within each of the Acquirer and Supplier organizations as well validating that Supplier Concepts satisfy Acquirer needs. Even with large Concept Multiplicity, MBCD models will support high levels of review of Concept Compliance as well as supporting review of Concept Strength
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
7 so as to assure that the Agreed Concept arising at the conclusion of the Concept Development phase has technical and business merit and a high probability of progressing into a successfully deployed system.
2. Model-based capability in fire and emergency services Daniel Spencer Aerospace Concepts Pty Ltd Introduction The Government of Western Australia’s Department of Fire and Emergency Services (DFES) is responsible for coordinating emergency services for a range of natural disasters and emergency incidents across Australia’s largest state. Acquisition, management and organisation of the department’s capabilities are large and complex tasks. In the simplest terms, capability for the department is the ability to deliver effective fire and emergency services. To achieve a capability requires the synchronised effects of a number of elements and the integration of them in the operational environment. A capability involves elements of the department’s assets, people (including their individual skills and competencies), established organisational knowledge, Information and Communication Technologies (ICT) and overarching governance and accountability. It needs to take into account complex organisational boundaries, including the various responsibilities of local brigades, private operators and other government departments, and various agreements between them. In 2013, DFES initiated a Capability Framework as a model to define, describe and document the range of characteristics and elements necessary to deliver their organisational capabilities.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
8 The Capability Framework Prior to the introduction of a Capability Framework, DFES has had a good basis in meeting local risks and needs with required equipment. The skills and competencies of its people have been enhanced by the deep experience and knowledge of many dedicated emergency services personnel, as well as significant structured training programs. Significant amounts of the tasks required in the department are well documented through established procedures and operating standards. In addition, the department has in place a program of producing high-level strategic plans on each of these capability areas linking to the department’s main strategic vision. The need for a Capability Framework was identified to fit between all of these areas, by linking the high-level strategies to the implementation and acquisition of each element involved in capability. The implemented framework also links each capability with the higher mandated need for the capability, for example in legislation, government regulations and state emergency plans, providing the basis for traceability from the lowest-level decision to the mandate for each capability. The Capability Framework developed provides a comprehensive model of system architecture so that all views of a capability are integrated and consistent. The Capability Framework includes: • A Tool The elements making up DFES capabilities and their relationships can be stored and accessed through models stored in a relational database. A series of customised Microsoft Excel, Microsoft Word and HTML outputs of the tool are produced, providing a persistent knowledge base of the Capability model.
• Structure A Reference Model, as an entity-relation model of the data elements that define how Capability is to be analysed, designed and stored as part of the DFES Capability Framework. • Processes A set of standard processes are defined for capability management and development, which identify how information is captured and used within the Capability Framework. • Glossary Defining a department-wide set capability management and development terms, and definitions of common fire and emergency services terms used throughout the described capabilities. A feature of the framework, and the framework tool, is the ability to produce both standard and customised products as reports or views of the data within the framework. Use of a Model-Based Approach The tool used for the development and initial implementation of the Capability Framework for DFES was Vitech CORE®. Using this model-based systems engineering tool, along with a model-based approach to the management and development of capabilities, allows a consistent, yet flexible structure for the Reference Model. The alternative approach for storage of the data would have been either a customised or off-the-shelf database management system, which was considered less desirable in the early stages of development, giving less flexibility and adding much higher cost of changes to the model structure. Using standard tools and methods allowed for the leveraging of existing enterprise architecture frameworks such as AUSDAF, DoDAF and
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
9 TOGAF, such that only minor changes were needed to meet the specific requirements of DFES. Presenting the capability models in formats from systems engineering (e.g. functional flows, interface block diagrams) enhances communication of the ideas investigated in the analysis. These views are presented from the underlying data model, which provides consistency between them and any other textual and tabular outputs produced. Current State For the initial implementation of the framework, the complete capability framework has been designed and established in consultation with department staff and associated stakeholders. This has included defining the interfaces between the data models produced under the framework, and other DFES processes and systems, such as those used by existing asset management, project management and risk management activities. In addition, in order to validate the tool and introduce its usage, a high-level definition of the department’s major capability areas has been completed, with three initial existing end-to-end capability models being developed. Benefits of the model-based approach to capability analysis and design A key feature of the model-based approach is the ability to show the traceability of all detailed elements that exist in the department (Assets, People, ICT, Knowledge and Governance and Accountability) to the capabilities they form and on to the mandates for these capabilities (such as legislation, regulations and state emergency plans). Enforcing traceability is supported in the model-based approach by generating reports on
model completeness. This gives the significant benefits of: • recording and communicating a sound mandate and basis of requirements for projects; • making clear the implications of capability decisions to decision-makers at all levels of DFES; • providing defensible support and internal justification to capability decisions; • informing government of DFES capabilities; • protecting projects and capability requirements from financial or other external pressures; and • will ultimately will increase the efficiency of expenditure across the department. Providing an integrated model of all DFES capabilities aims to optimise the use of common capability elements. In addition to this, the extensibility of the model supports such activities as: • developing business requirements using both bottom-up and top-down approaches; • capability options analysis for new and upgraded capability projects; • developing business cases (“New Additional” funding) for capability that are inherently robust; • developing of specifications for tenders / acquisitions / contracts directly from the model data; • evaluation of tenders / acquisitions / contracts against the model data; • identification of risks relating to capability gaps and inform risk assessment and management; and • recording lessons learned from capability projects and determine what action is to be taken.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
10 About Daniel Spencer Daniel Spencer is a systems engineer at Aerospace Concepts Pty Ltd. He has over a decade of experience in design and development of systems solutions across a broad range of industries, both in Australia and the United Kingdom. Dan holds a Bachelor of Engineering in Information Technology and Telecommunications from the University of Adelaide. He has been working with Australian Defence clients developing and refining tools and methods for a repeatable and comprehensive MBSE method, while using this approach for real-world capability definition and development projects. Daniel was the project manager and technical lead for the recent Western Australian Department of Fire and Emergency Services project to design and implement a Capability Framework.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
11
3. An assessment of Model-Based Systems Engineering (MBSE) through the SysML modelling of the Mascot Asteroid Lander system Michael Kretzenbacher Monash University Ross Findlay Germany Caroline Lange Germany Dr Wenyi Yan Monash University Introduction Modern systems engineering practices typically involve much concurrent work, ranging from work undertaken between individual engineers to international co-ordination between multiple organisations. In order for this concurrent approach to be successful, systems engineering requires effective communication and documentation. A shift towards Model-based Systems Engineering (MBSE) may provide a more effective way for systems engineers to manage and document project progress. This notion was explored through the construction of a Systems Modelling Language (SysML) model of the DLR MASCOT asteroid lander system in order to demonstrate the applicability of MBSE to such a project. MBSE is the application of modelling to support aspects of systems engineering such as system requirements engineering, system design, analysis, verification and validation, from system conceptualisation, to later system life stages.1 MBSE is of interest to the systems engineering discipline as it offers significant potential benefits to communication, specification and design
precision, design integration, and reuse which could improve design quality, productivity, and reduce development risk.1 The Systems Modelling Language (SysML) provides one way in which a model for MBSE can be created. SysML is a general-purpose graphical modelling language that supports the analysis, specification, design, verification and validation of complex systems.1 As SysML was developed in 2006, there has so far only been limited research into the use of SysML for MBSE.2 SysML has seen some use in the automotive industry, such as the application of the requirement capturing and behavioural modelling capabilities of SysML for the AUTOSAR Automotive Open System Architecture (AUTOSAR) automotive software standardisation initiative.3 A few studies have also evaluated the use of SysML for MBSE in space applications, such as a cube sat modelling study4, a study on the use of SysML in early phase mission design in a concurrent environment5, a telescope system modelling study6 and a Jet Propulsion Laboratory study.7 These studies all focussed on phase 0 or A, the early phases of space system design and development. The life cycle of a space project is typically divided into 7 phases, including phase 0, mission analysis and needs identification; phase A, feasibility; phase B, preliminary definition; phase C, detailed definition; phase D, qualification and production; phase E, utilisation and phase F, Disposal.8 The use of SysML based MBSE in the later design and definition phases of B and C does not appear to have been researched as much as usage in early design phases. Thus, this project sought to answer how SysML based MBSE could be used to benefit the systems engineering process during the later design and development phases B and C of a space project.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
12 The Mobile Asteroid Surface Scout (MASCOT) Lander, developed by the German Aerospace Centre (DLR) and the Centre National d’Etudes Spatiales (CNES), provided a suitable system to be modelled with SysML for this project. MASCOT is a small (~10kg) asteroid lander that will be carried by the Hayabusa 2 spacecraft, developed by the Japan Aerospace Exploration Agency (JAXA), to the Asteroid 1999 JU3, where it will take in situ scientific measurements.9 This system was a useful test case with which to assess SysML based MBSE, as it is a relatively small system, and so was possible to model by one person, but is still quite complex and thus was able to show the scalability of modelling in SysML. During initial research into space systems engineering and SysML based MBSE, three areas became apparent where a SysML model could provide useful in later stage systems development: communication, documentation and situational awareness within the system. The benefit to project communication was investigated by assessing whether a SysML model could improve the communication of system aspects within a project group as well as in the delegation of a task, and whether a SysML model could provide a useful resource for handover and the introduction of new engineers to a project. The current form of documentation used for the development of the MASCOT system was explored in order to assess whether a SysML model could provide a more effective method of documentation than traditional technical documents. Karban et al. state that the products of engineering fields cannot be designed and built standalone as they influence each other mutually and an optimal balance is to be found. 6 Any changes made to a single subsystem or
component of a space system can affect other systems and components. Thus, the benefit of SysML based MBSE to the situational awareness of the system was assessed by modelling the interrelations between subsystems and components, in order to see whether a graphical model of these interrelations could assist in managing system complexity. Project structure The SysML modelling of the MASCOT System was done on site at the German Aerospace Centre (DLR) Institute of Space Systems in Bremen, Germany, between December 2012 and June 2013. This study was a ‘shadow’ study and was not directly incorporated into the development of the MASCOT system. The system was modelled using information from phase B and C of the development of MASCOT. The SysML modelling of the MASCOT system was done in two stages. First, a general model of the MASCOT system and mission was created based on information from phase B development of the system. The general model was split into the MASCOT system and the MASCOT mission. MASCOT was modelled in a ‘top-down’ recursive structure, with each ‘level’ increasing in detail starting with a broad system overview. At each level, the model was organised by sorting the SysML objects and diagrams into requirements, behaviour or structure. Two case studies were then undertaken using more detailed information obtained from MASCOT development in Phase C. The first case study involved the detailed modelling of a subsystem consisting of MASCOT Guidance Navigation and Control (GNC) sensors. This was done in order to find what aspects of a system can effectively be modelled in SysML in detail, as well as the limitations of SysML in the modelling of certain types of information. The second case
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
13 study involved the modelling of the procurement process of the MASCOT battery system. This case study investigated the use of SysML in the communication between organisations involved in a procurement process as well as exploring the documentation of the process. A suitable method to access and display the MASCOT SysML model beyond the modelling software was also investigated.
SysML is a tool independent modelling language and is not limited to any specific software. For this project, the DLR used MagicDraw UML version 17.0.3 SP1 with the MagicDraw SysML Plug-in version 17.0.3 from No Magic, Inc as well as the ParaMagic Plug-in version 17.0.2 from InterCAX LLC, with OpenModelica version 1.7 by Open Source Modelica Consortium used as a core solver. BEHAVIOUR,
The model of the MASCOT System created as part of this study was not a complete model of the entire MASCOT system. It was created to serve as a test bed with which to assess SysML based MBSE and was not intended for use beyond an example SysML model.
Requirement and structure modelling The various SysML diagram types can be split into three main subsets, including the requirement diagram, behaviour diagrams and structure diagrams.1 Behaviour diagram types
Figure 1
include the activity, sequence, state machine and use case diagrams, while structure diagram types include the block definition, internal block,
An activity diagram portraying the MASCOT decision making process.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
14 parametric and package diagrams.1 Examples of all of these diagrams were created for this project. Behaviour modelling was found to be very useful in the portrayal of the MASCOT mission. It was possible to link other diagrams to elements within a broader diagram. An example of this existed within the activity diagram describing the surface operations of MASCOT, which can be seen in figure 1. Within this diagram, there is a ‘Detect Attitude’ action. In this diagram, this action is linked with the system that conducted the action (the GNC system) through a segment of the activity diagram dedicated to the system that undertakes it, known as a ‘swim lane’ (the vertical segment seen in the figure). Activity diagrams proved adept at providing flow-charts to effectively visually describe interactions between subsystems and sequences in the decision making process of the MASCOT operations. Sequence diagrams allow interactions between systems such as inter-system communication to be portrayed on a timeline allowing the order of specific sequences involved in a process to be clearly graphically represented. As with the activity diagram, it was possible to link elements within the sequence diagram to relevant other parts of the model, such as the subsystems and components involved. Requirement diagrams showed promise in the tracing of system requirements, as they allow for simple visual confirmation that any modelled requirement is satisfied by a system component or subsystem, and that this can be confirmed through a test case. Structure diagrams allowed the structure of a system to be portrayed. These were useful in both the modelling of the physical structure of
MASCOT as well as the systems structure. Structure diagrams allowed for the interrelation and connection of subsystems and components to be modelled. Numerical relations could be visually represented through parametric diagrams. The ParaMagic plugin makes it possible for these interrelations to be made executable, so that an output is given. Case study outcomes The first case study involved the detailed modelling of a Guidance Navigation and Control (GNC) system in the MASCOT lander. This system comprised of a series of LED Photodiodes, used to detect spacecraft attitude by reflecting light off of the asteroid surface. During the case study, the sensors themselves were modelled, as well as their internal structure. Three alternative configurations of the sensors and their connection with the on board computer (OBC) were also modelled, as well as a sensor test case. In this case study, it was determined that modelling a system in SysML has a point of ‘diminishing returns’. SysML was found to be useful in providing an overview of system aspects, in modelling the behaviour of the subsystem, as well as modelling interactions between subsystems and components. Large and specific collections of information such as graphs, tables and schematics are not as easily modelled. While Numerical values can be allocated in SysML to blocks representing a part or component of the system, allocating a large volume of information to any block becomes very labour intensive. It was determined that dedicated software, such as Microsoft Excel, is far more effective than SysML for these purposes. This reaffirms Krueger’s statement that while it is in principle possible to describe an entire system in SysML, in practice the modelling of the subsystem will be done until a certain
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
15 level of detail is met, after which the specialised modelling and simulation programs take over.10 It is possible, however, by using MagicDraw and the ParaMagic plugin, to include images of tables, graphs and sketches, or hyperlinks to external files, and so it is still possible to include this information within a SysML model. The second case study involved the modelling of the procurement process of the MASCOT battery system. The MASCOT battery is being developed by SAFT under CNES contract and responsibility, and thus this test case provided an opportunity to examine how a SysML model would be effective in the communication involved in inter-organisational co-operation, or in the
Figure 2
communication required during the procurement of a system from a subcontractor. This case study involved the modelling of various design iterations of the MASCOT battery system in detail. Requirement diagrams were created in order to model the division of labour at certain stages between the DLR and CNES using documentation of meetings. Interfaces between the battery system and the greater MASCOT system were modelled using internal block diagrams containing nested ports to represent various connections and interfaces. It was found that a SysML model provided a useful method of communication in a procurement process due to the modular nature
Detail of the Internal Block Diagram portraying the mechanical interactions between MASCOT subsystems
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
16 of modelling in SysML. It is possible to model an entire subsystem, such as the battery, on its own. A copy of this model can then easily be added to a larger central MASCOT model. It is also possible to control how much information is conveyed to another organisation or subcontractor, by varying how detailed the SysML model components provided to them are. Black box SysML representations of other systems that connect with the battery, could be provided to an external organisation. Such a ‘black box’ model element is an element only showing relevant external information, such as how it connects to the MASCOT battery, without providing detailed information of the system component it represents. It was thus found possible to use SysML to provide contextual information for a procurement process, while controlling the amount of information shared.
subsystem. The new team member can use the model structure to find direct information on the system they are working on, as well as contextual information on systems and components that interact with their system.
Communication, documentation and systems interaction Throughout this project, the possible benefits for project communication and documentation as well as systems interaction were explored. A central SysML model used in the development of a space system was found to be useful for project communication as it could aid project
At the time of completion of the MASCOT SysML study, the development of MASCOT had generated over two hundred individual submitted documents. This number represents around half of the final expected number of documents generated by the development of the MASCOT system. A central SysML model of a system like MASCOT could provide a useful single reference point to be used during development. Certain values could be added to the model in order to ensure that all concurrent teams are working using the same parameters. The central model would provide a useful starting point for engineers looking for certain values, without having to sift through numerous documents. A SysML model can be ‘published’ in an html format using the web publisher feature of the MagicDraw software. This makes it possible for the model to be accessible for numerous team members, without having to invest in more software licences than necessary for the system modelling. This would also ensure that only predetermined team members, such as the project system engineers, could edit and alter the model, allowing changes to be tracked more effectively. More detailed documents and files, not suitable for modelling in SysML, can
handover and be used for external technical communication during procurement. An inherent difficulty in project handover or the introduction of a new team member to any project is the sheer amount of information that needs to be conveyed. A SysML model divides the model along subsystem and component lines, making it easier for the introduction of a new team member to the development of a
be linked within the model using hyperlinks. A SysML model can thus be used as a central data depository that links external documents while describing the system itself. The modelling of any common component or system was also found to be useful, as the SysML model of this part or system could be added to the SysML model of a future or follow-on system, demonstrating the re-usability of parts of a SysML model.
Finally, the modelling of various iterations of the battery development proved that a SysML model could provide effective documentation of design changes throughout a system development.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
17 A very important aspect to the systems engineering practice during phase B or C is the monitoring of how design changes made in a system affect other systems and parts of the project. A SysML model can provide a visual portrayal of how a subsystem interacts with other subsystems within the project, making it easier to monitor which systems could be affected by changes. This was demonstrated by separately modelling the electrical and mechanical interaction of subsystems within the MASCOT system. An example of this can be seen in figure 2, containing a detail of an internal block diagram representing the mechanical interaction between MASCOT subsystems. By tracing the system interactions shown in the diagram, a checklist can be created, to list what systems need to be investigated to gauge the impact of any given design change. The numerical impact of certain changes, such as changes in mass, can directly be assessed using parametric modelling, as the updated values will be used, without having to rewrite the parametric relations. Lessons learned and conclusion A number of lessons applicable to future studies on the use of SysML in the systems engineering of space system were learned during the course of this study. First, SysML has a very difficult learning curve. Due to the flexibility of the language, there is a lot of ambiguity as to how something should be modelled. It was found to be a difficult language to learn without experienced guidance. A training course in SysML could greatly improve this, and save a lot of time in the initial stages of a SysML project conducted by inexperienced modellers, although this will also contribute to project costs. Version tracking was found to be very important in the creation of a central model, especially if the model is edited by more than one user, as
this reduces mistakes and the possibility of one user ‘overwriting’ the work of another, as well as making it easier to document previous design iterations. It is recommended that a catalogue of modelled parts is created and maintained throughout the modelling of a system. This provides a single location to find any given modelled part of a system, and also increases the reusability of a model, as common or re-used parts can be taken from existing SysML models and incorporated into new ones to reduce modelling effort. This study was undertaken in the middle of the development of the MASCOT system. This meant that extensive modelling was required in order to meet the extent of the system developed to date. A more time efficient modelling practice would be to model the system incrementally in parallel with the design process. This would make it easier for trade studies to be documented within the model and would spread the workload over a longer time. It would however either require an existing staff member to be trained in SysML and to model the system while also working on their main role in development, or would require the creation of a position for a dedicated systems modeller, who would need to remain attached to the project throughout the system development. There appeared to be a lack of openly available materials to aid in the training of modelling within SysML, particularly materials specific to modelling a space system. Additionally, the ambiguity inherent in modelling in SysML could provide difficult. In order to reduce this ambiguity, it is recommended that either an organisation, or even space sector, standard modelling methodology be developed, in order to standardise modelling practices and aid in coordination between multiple SysML modellers. A standard set of training materials based on such a methodology for the use of SysML in the
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
18 modelling of a space system could provide a useful resource for future SysML users, as well as promote these industry standard practices. The Model-Based methodology to support Space System Engineering (MBSSE) provides guidelines for modelling a system in phases 0, A and B, and so fulfils this role to an extent.11 This methodology could be expanded upon, by providing specific guidelines to modelling common space system aspects and components from early design through to qualification and production. A more detailed methodology and set of training materials would greatly assist in easing the learning curve and promoting the increased implementation of SysML based MBSE using industry standard practices. It was found that it was possible to add executabilty to a central SysML model, but that this aspect was not as efficient as the use of dedicated software. The results from such dedicated software can however be integrated into a central SysML model. A possible current application for a SysML model of a space system is for it to be used as the basis for the creation of a central data depository that follows the system structure and portrays information in itself while also providing links to external documents and files. The suggested next step for research into the use of SysML in the Model Based Systems Engineering of a space system is for a complete SysML shadow study to be undertaken. Such a shadow study would involve the modelling of the development of a space system throughout the development process, in order to assess how a SysML model is useful at various design phases and whether it provides useful documentation for an entire development process. There are clear benefits to adopting
MBSE with SysML into the process of developing a space system. The greatest benefits would be seen in complex large-scale systems, due to the modular and reusable nature of SysML. In smaller scale systems, the benefits do not yet appear to outweigh the time, manpower and financial resources required for the successful implementation of MBSE. MBSE will need to be successfully implemented in small-scale space projects before it can extended to larger projects, and so MBSE for space applications will need to be further developed in order to become more enticing for small-scale space system applications.
References 1 Friedenthal, S., Moore, A., Steiner, R. 2008, “A Practical Guide to SysML: The Systems Modelling Language”. Morgan Kaufmann OMG Press, Burlington, MA. 2 Maurandy, J., Gill, E., Helm, A., Stalford, R. 2012, “CostBenefit Analysis of SysML Modelling for the Atomic Clock Ensemble in Space (ACES) Simulator”, Delft University of Technology Space Systems Engineering & EADS Astrium GmbH. [Online] Available at: http://www.lr.tudelft.nl/fileadmin/Faculteit/LR/Organisatie/ Afdelingen_en_Leerstoelen/Afdeling_SpE/Sp ace_Systems_ Engineering/Publicaties/Incose_2012_Maurandy_283341.pdf 3 Boldt, R. 2007, “Creating AUTOSAR Systems Models Using the Combined Power of UML and SysML.” [Online] Available at: http://www.ai-online.com/uploaded/Creating_AUTOSAR_ Systems_Models_Using_UML_and_SysML.pdf 4 Spangelo, S., Kaslow, D., Delp, C., Cole, B., Anderson, L., Fosse, E., Gilber, B., Hartman, L., Kahn, T., Cutler, J. 2012, “Applying Model Based Systems Engineering (MBSE) to a Standard CubeSat“ University of Michigan, Jet Propulsion Laboratory, NASA & SRI International, [Online] Available at: http://www.omgSysML.org/Applying_MBSE_to_a_Standard_ CubeSat- Space_Systems_Challenge_Team.pdf 5 De Lange, D. 2011, “Applicability of SysML to the Early Definition Phase of Space Missions in a Concurrent Environment”, Delft University of Technology, Delft. 6 Karban, R., Zamparelli, M., Bauvir, B., Koehler, B., Noethe, L., Balestra, A. 2008, “Exploring Model Based Engineering for Large Telescopes – Getting started with descriptive models”, European Southern Observatory, [Online] Available at: http:// www.eso.org/sci/libraries/SPIE2008/7017-55.pdf
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
19 7 Mandutianu, S. 2009, “Modelling Pilot for Early Design Space Missions”, 7th Annual Conference on Systems Engineering Research 2009 (CSER 2009), 20-23 April, Loughborough University, [Online] Available at: http://cser.lboro.ac.uk/papers/S02-13.pdf 8 European Cooperation for Space Standardisation (ECSS), 2009, “Space Project Management: Project Planning and Implementation”, ECSS Secretariat, ESA-ESTEC, [Online] Available at: http://www.skatelescope.org/public/2011-11-18_ WBS-SOW_Development_Reference_Documents/ECSS- M-ST10C_Rev.1(6March2009).pdf 9 Findlay, R., Ho, T. M., Lange, C., Wagenbach, S., Witte, L., Ziach, C., Biele, J., Krause, C., Ulamec, S., Spohn, T., Okada, T., Yano, H. 2012, “A Small Asteroid Lander Mission to Accompany Hayabusa II”, Session 4: Small Bodies Missions and Technologies, A3: Space Exploration Symposium, 63rd International Astronautical Congress, 1-5 October, Naples, Italy, International Astronautical Federation. 10 Krueger, T. 2011, “Modelling of a Complex System in a Model Based Design Approach” European Space Agency, ESTEC. [Online] Available at: http://robotics. estec.esa.int/ASTRA/Astra2011/Papers/01B/FCXNL11A06-2144573-1- 2144573Krueger.pdf 11 Mazzini, S., Puri, S., Olive, X., Burte, G., Paccagnini, C., Tronci, E. 2009, “Report 3: Guidelines for Model Based Space System Engineering”, System and Software Functional Requirements Techniques, Issue 1.2, pp. 1-156.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
20
4. MBSE - Navigating mindsets and perspectives Meredith Hue DSTO It’s a statement of the obvious: that modelling principles and techniques are fundamental to notions of model-based systems engineering (MBSE). When exploring the more elaborate notions of MBSE as applied to Defence, taking on particularly difficult and complex problems, it is essential to ensure there is sufficient common understanding of the underlying fundamental principles of modelling within the stakeholder community of concern. The concept of a system model is explored in the engineering context in terms of the purposes it can serve and the types of analyses it can support. Various modelling approaches are examined including real world modelling, conceptual modelling, decision modelling, architecture modelling, and data modelling. The significance of the modelling language is also explored along with modelling methodologies and methods of model representation. The implications are then considered in the context of the Defence capability acquisition process. About Meredith Hue Meredith is Director of Systems Integration Engineering at the Defence Systems Integration Technical Advisory. Meredith undertakes research and provides advice on principles and practices supporting major capital equipment acquisition by Defence. A former Chief Engineer, she has 35 years experience as a systems engineering practitioner, both in Industry and Defence, in areas including real-time systems, combat systems and military communications. She joined DSTO in 2001, and has a particular interest in methodologies supporting capability development of Defence’s future warfighting capability.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
21
5. The challenge of review in a model-based world Michael Waite Aerospace Concepts Pty Ltd In recent times, much has been said of model-based approaches to systems engineering. Whilst systems engineers have always used models in various forms (mental models, diagrams, documents, etc), it has not been until the advent of modern model-based software that the intention of MBSE is truly being realised. These software packages have revolutionised the world of MBSE and continue to do so. But with this revolution comes many challenges. In particular, a number of engineering processes that are necessary in the execution of systems engineering, need to be reconsidered and updated to align with the burgeoning progress being made in the MBSE world. A key process is the conduct of reviews, which is the focus of this presentation. In simple terms, a model is a representation of reality. Davis et al (1993) proposes knowledge representation as a surrogate. The knowledge representation is considered an abstraction of a real world thing or concept that an action cannot be performed or it is undesirable to occur at that point in time. These models are used to facilitate shared understanding and support decisionmaking. Engineering models can be of many forms including physical models (scale model), information (relational database), and drawings (CAD model). Reviews are a process whereby a design is evaluated against its requirements in order to verify the outcomes of previous activities and identify issues before committing to further work. This may occur at any point in the system
lifecycle, with the design of one stage forming the requirements of the next. Additionally, reviews are essential to ensure that the system being developed will meet requirements and that the requirements are understood by the development team. Formal reviews are essential to determine readiness to proceed to the next stage of the system life cycle. The number and frequency of these reviews and their associated decision gates must be tailored for specific projects (INCOSE SE Handbook v3.2, pg 184). The MBSE domain need not change the objective of reviews outlined above. However the method in which reviews are conducted need to adapt in order to contribute to the realisation of benefits espoused by MBSE advocates. Therefore the key systems engineering guidance documents are examined for detail. ISO1220 (2005) states that each technical review should accomplish the following: a) Assess the system requirements and allocations to ensure that requirements are unambiguous, consistent, complete, feasible, verifiable, and traceable to top-level system requirements b) Assess the design maturity based on technical development goals, Systems Engineering Master Schedule events and accomplishments, and empirical analysis and test data supporting progress to date c) Present the risks associated with a continued development effort d) Assess the life cycle processes and infrastructure necessary for product sustainment throughout the system life cycle e) Identify resources required for continued development f) Determine whether to proceed with the next application of the Systems Engineering Plan, to discontinue development, or to take corrective actions before proceeding with the development effort
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
22 The review of a document is (relatively) linear. The review begins at the front of the document, and continues until the end. Documents are developed that tell a story for ease of understanding by the reader. In the conduct of reviews the review team will assess the information, identifying issues and leaving comments either in the document itself, in a separate review record, or often, both. MBSE software packages generally include the functionality to export model information into document format. Robinson (2012) notes that the information retained within the model can generate the same documentation through a scripting language querying the model and exporting the information to the document. As such, it is possible to review the outputted documentation from the model in the same manner as described above as a proxy for the model itself. It is possible to continue in this way, gaining the traceability, consistency and sharing benefits of using a model-based approach, while maintaining the traditional document review process. The next step is to further leverage model and conduct reviews directly on the model itself. A number of issues arise when considering how to directly review a model. These include: • How do you “see” a model? • How do you see the right information at the right level to avoid information overload? • How do you “mark-up”, or leave notes / comments, in a model?
References Davis, R., Shrobe, H., & Szolovits, P. (1993). What is a Knowledge Representation. AI Magazine, 17-33. Robinson (2012), A discussion on the fitness for purpose of the model produced in a model-based systems engineering process, proceedings from SETE 2012, Brisbane, Australia International Council on Systems Engineering (INCOSE) SE Handbook Working Group (2010), Systems Engineering Handbook v3.2, INCOSE, San Diego, USA. IEEE Std 1220-2005 (2005) Systems engineering - Application and management of the systems engineering process, Institute of Electrical and Electronics Engineers, Inc. New York, USA
About Michael Waite Michael Waite has been working as a professional engineer for over ten years since completing his Bachelor of Engineering (Mechatronics). His career has seen him working for several multi-national companies in Australia, Asia and Europe, including Mitsubishi Motors, Ford and Caterpillar. He currently works for Aerospace Concepts, a systems engineering consulting company, specialising in the development of complex-system capabilities. Michael has an interest in applying model-based systems engineering, particularly in the conceptual design phase, and is also the cochair of INCOSE’s Model-based Conceptual Design (MBCD) working group.
This presentation will examine the benefits to be gained by using this approach and will discuss preliminary ideas for implementation of a direct model review process.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
23
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
24
6. The problematic situation (streamed from o/s) Jack Ring Educe LLC Abstract not available at time of print.
About Jack Ring Jack Ring, BA, Physics, was advanced system projects manager at GE for 20 years, product line director at Honeywell for 10 years, then enterprise development leader at Edelbrock Corp., Ascent Logic Corp., and IBM Object Technology Practice and coach of several high tech startups the last 25 years. He is a Fellow, International Council on Systems Engineering, Industrial Fellow, Stevens Institute of Technology, School of Systems and Enterprises, and Senior Analyst, Cyon Research Corp. He is a Member, International Society for the Systems Sciences, International Test and Evaluation Association, IEEE-SMC, and Association for Computing Machinery. Current interests are Managing Member, OntoPilot LLC, Member, Educe LLC and Member Kennen Technologies LLC. He claims to be the first person to use telemetry on a race car, 1959.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
25
7. Model-based conceptual design: Integration of analysis requirements into the WSAF Schema Despina Tramoundanis DSTO Major Timothy Walmsley Australian Army The Whole of System Analytical Framework (WSAF) is a Model Based System Engineering (MBSE) methodology hosted in Vitech’s CORE® software. The WSAF comprises four key components: • A meta-model that defines the knowledge classes and the inter-relationships between these classes, providing structure to the knowledge model. • A knowledge model that describes the architectural perspectives of behaviour, physical form, purpose, data, performance, and managerial aspects of the capability of interest (Maier & Recntin 2009).
Figure 1
• A process and methods for developing the knowledge model content. These are aligned to the Defence Capability definition guidance and systems engineering best practise such as described in the INCOSE Systems Engineering Handbook (INCOSE 2012). • Scripts that are executed to auto-generate the capability definition documents. Initially, the WSAF was applied to develop the analysis requirements for major capital equipment projects (Robinson & Graham 2010). it was subsequently expanded significantly to develop the capability definition and requirements for several major defence projects (Robinson et al 2010, Tramoundanis et al 2010 and Tramoundanis & Jones 2012) The WSAF was further expanded to support technical risk analysis (Tramoundanis et all 2013). The present paper proposes the further extension of the WSAF schema to enable the incorporation of modelling, simulation and analysis (MS&A) requirements. This work was commenced
Simplified reference model for experiment design and metrics development (adapted from Robinson & Graham, 2010)
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
26 recently to support the design and development of a MS&A capability for Land 19, Phase 7B, a Ground Based Air and Missile Defence Project. Specifically, this paper proposes extension of the WSAF schema to support articulation of client questions, the derivation of study questions and the development of modelling vignettes and experiments as well as the associated measures of effectiveness. In this way, the MS&A design and the data extracted from the modelling are traceable to the capability options and key capability parameters such as the Critical Operational Issues (COIs) as well the capability missions and employment scenarios. The proposed schema extension allows the decision support analysis requirements to be integrated into the capability definition at the outset. Figure 1 presents a high level view of the proposed schema extension demonstrating the relationship between the defined capability requirements and the operational employment scenarios traditionally contained in the OCD and the MS&A capability design. At the centre of the proposed schema extension is the motivation to provide demonstrable traceability between the MS&A program and the capability definition. This serves the following important purposes: • It demonstrates the rationale underpinning the analysis program and its priorities; • It provides a sound basis from an early stage for evolving (iteratively over time) the requirements for the technical performance evaluation of tendered solutions and the identification of analysis products or technical data to be requested in tendered proposals. • In the event of a change in the capability requirements, it provides a means of assessing the impact in the design of vignettes and experiments and the associated metrics and data to be extracted from the modelling and simulation.
Note, there is no intent to include simulations in an MBSE tool environment because it would be too complicated an undertaking. The intent is to provide a robust means of developing and recording the MS&A requirements in an integrated fashion with the capability definition.
References Estefan, J.A., (2007) Survey of Model-Based Systems Engineering (MBSE) methodologies, INCOSE MBSE Focus Group, International Council on Systems Engineering INCOSE (2012) Systems Engineering Handbook Version 3, A Guide For System Life Cycle Processes and Activities, INCOSE-TP-2003-002-03.2.2 Maier, W.M., & Rechtin, E., (2009) The Art of Systems Architecting, Third Edition, CRC Press, Florida Robinson, K., Tramoundanis, D., Harvey, D., Jones, M., & Wilson, S., (2010) Demonstrating Model-Based Systems Engineering for specifying complex capability, Systems Engineering / Test and Evaluation Conference Robinson, K., and Graham, D., (2010) An improved methodology for analysis of complex capability, Systems Engineering / Test and Evaluation Conference Tramoundanis, D., Robinson, K., & Power, W., (2010) Adapting to accelerated acquisition: WSAF in LAND 19 Phase 7, Land Warfare Conference Tramoundanis, D., & Jones, M., (2012) A Process for solutionclass capability options design and analysis, Systems Engineering / Test and Evaluation Conference Tramoundanis, D., Power, W., & Spender, D., (2013) Integration Risk Analysis in an MBSE Environment, Systems Engineering / Test and Evaluation Conference
About Despina Tramoundanis Despina Tramoundanis was a Royal Australian Air Force Armaments Engineer for 20 years before joining DSTO’s Weapons Systems Division in 2002. She is currently the S&T advisor for a GroundBased Air and Missile Defence project. Her current research interests include development of the Whole-of-System Analytical Framework, a ModelBased Capability Engineering methodology for the provision of cross-Defence modelling, simulation, analysis and Capability Development activities. She holds a Bachelor of Engineering (Chemical)
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
27 from Monash University, an MSc in Explosives Engineering from Cranfield University (UK), a Master of Defence Studies from UNSW and a Master of Defence Operations Research from UNSW. About Major Timothy Walmsley Major Timothy Walmsley entered the Royal Military College in 2003, graduating to the Royal Australian Artillery in 2004. During his time as a junior officer he held command appointments in Air Defence at 16 Air Defence Regiment, and Surveillance and Target Acquisition at 20 Surveillance and Target Acquisition Regiment. During this time he deployed with the Target Acquisition Troop to Iraq in 2006 and was awarded a commendation by the US base commander for his commitment to force protection. Post Iraq, Major Walmsley was qualified as an Unmanned Aerial Vehicle operator and assumed the role of Battery Captain for a deployment to Afghanistan in 2008 with Unmanned Aerial Vehicle Group 4. In 2009, Major Walmsley fulfilled the role of Acting Battery Commander of 131 Surveillance and Target Acquisition Battery before being accepted into the Capability and Technology Management College in 2011. He graduated as a Capability and Technology Manager and was awarded a Masters of Management Studies. He has also completed a Masters of Project Management through UNSW. He was posted to Capability Development Group in 2012 and has been fulfilling the role of Senior Project Manager of LAND 19 Phases 7A and 7B
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
28
8. “All for the want of a horseshoe nail”: An examination of causality in DoDAF (streamed from o/s) Matthew Hause Atego Lars-Olaf Kihlstrom Syntell AB The title of the paper refers to the death of Richard III of England at the Battle of Bosworth Field. The full text of the proverb is the following: “For want of a nail the shoe was lost. For want of a shoe the horse was lost. For want of a horse the rider was lost. For want of a rider the message was lost. For want of a message the battle was lost. For want of a battle the kingdom was lost. And all for the want of a horseshoe nail.” The example shown above refers to a trivial event that commences a sequence of other events eventually evoking a far more grave consequence. This is often referred to as a chain of causality of causal sequence. Often these chains of causality are only seen in hindsight when the true cause and effect of the sequence can easily be seen. One example is the 2012 Northeast USA blackout. When the sequence was eventually examined, the cause was found to be reversed polarity on a sensor in combination with hot weather and electrical conductors contacting with trees that had not been trimmed due to budget cuts at an electric company. In this case, a series of circumstances caused the blackout, but the sequence nonetheless was cause by a set of unremarkable circumstances any one of which would not have caused the blackout. Similar constructs are the vicious circle where a circular chain of events causes a situation to inexorably deteriorate. Family dynamics, budget cuts in a
failing organization and environmental pollution are all examples of this. The situation in Pakistan/ Afghanistan regarding drone strikes inadvertently killing civilian causing radicalisation leading to more drone strikes is another example. The reverse situation is referred to as a virtuous circle where a series of events causes a situation to improve. An industrial example would be increased production efficiency leads to reduced costs leads to lower prices leads to an increase in output leads to learning curve effects leads to economies of scale and back to the beginning. Value chains such as these are commonly identified in industry and well documented. These are often modelled using such techniques as system dynamics. System dynamics is an approach to understanding the behaviour of complex systems over time. As well as causal sequences, it deals with internal feedback loops and time delays that affect the behaviour as well as the state of the entire system. What makes using system dynamics different from other approaches to studying complex systems is the use of feedback loops and stocks and flows. These elements help describe how even seemingly simple systems display baffling nonlinearity. These techniques can also be used to determine the causes leading to undesirable outcomes. As stated above, these sequences are often not identified until after the event has occurred. However, once in an unfavourable situation, it is useful to examine how the situation has arisen and determine how to mitigate the causal factors and reverse the sequence. The Business Motivation Model (BMM) published by the OMG also contains concepts useful to evaluation more referred to as soft systems methodology. “BMM captures business requirements across different dimensions to rigorously capture and justify why the business wants to do something,
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
29 what it is aiming to achieve, how it plans to get there, and how it assesses the result.” [OMG, 2010] The main elements of BMM are: Ends: What (as oppose to how) the business wants to accomplish. Means: How the business intends to accomplish its ends. Directives: The rules and policies that constrain or govern the available means. Influencers: Can cause changes that affect the organization in its employment of its Means or achievement of its Ends. Influencers are neutral by definition. Assessment: A judgment of an Influencer that affects the organisation’s ability to achieve its Ends or use its Means.
Figure 1
DoDAF 2.0 contains many concepts that would help to document these sequences as well as the dynamic elements, feedback loops and influences. This paper will examine different scenarios and show how the addition of BMM and Systems Dynamics can help to document these sequences as well as what a DoDAF model would be able to show relating to the sequence. This will provide decision makers a more effective set of tools to evaluate operational scenarios as a means of improving outcomes. The scenario chosen to illustrate a sequence where the root cause of the problem turned out to something rather small has to do with wounded soldiers being evacuated from an operation. The IDEAS foundation, on which DoDAF is based, contains elements that lend it to causality discussions, both as regards instances of things as well as types of things. The IDEAS/
Medical journal temporal relationships and their parts
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
30 DoDAF meta-model is used to describe the problem above by going from the large to the small as successive layers of detail is revealed by the model and causality reveals the issue as the root cause of the problem. The IDEAS foundation elements such as beforeAfter, BeforeAfterType as well as happensIn, Duration and startBoundary and endBoundary plays a key role in determination of proper causality and the ability to deal with these kinds of elements is key to the proper handling of causality chains. The presentation also details some of the additional power brought to bear by the use of MODEM, the candidate framework for the next version of the NATO Architecture framework (NAF version 4). MODEM is essentially the UK MODAF framework re-engineered such that what used to be a UML based profile is now a meta-model based on the IDEAS Foundation, i.e. it has the same basis as DoDAF 2. Figure 1 demonstrates some of the time based causality handling that can be included using IDEAS/ DoDAF/ MODEM. The Figure implies strictly that Patient A med journal 1 ceased to exist prior to Patient A medical journal 2 coming into being. It also strictly implies that Patient A travel itinerary forms a part of Patient A medical journal 2. The example include expands on this and demonstrates how this is part of the causality chain that describes the problem. The method for how to attack a problem where causality needs to be revealed is also discussed.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
31
9. Modelling and management of relationships between military SoS Dr Pin Chen DSTO Dr Mark Unewisse DSTO Military Systems-of-systems (SoS) vary and are created for various purposes in different contexts, ranging from information-based systems to Networked Centric Operations (NCOs). These military SoS are related in various forms of relationships, which is one of main contributing factors to high complexity of SoS. It is these relationships that on one hand could make military SoS become more capable, effective and efficient, but on the other hand test not only ability of various engineering approaches and methods but also capability of defence organisations in conceptual design and engineering of modern force and capabilities. Various and complicated relationships between military SoS, if not handled properly, cause increases of uncertainties, disagreements and costs, which directly contribute to risks, delays and failures in capability development and acquisition, and make force generation, integration, campaign planning and operation be much more complicated and difficult. Conceptual design of force and capabilities is supposed to provide solutions for modelling and management of these relationships such that uncertainties, disagreements and risks can be effectively managed and reduced. In the current practice, however, poor understanding on military SoS and their complicated relationships has significantly undermined the effectiveness and efficiency of many analysis and engineering activities since many engineering or architectural approaches
used often fail in providing clear guidance on and solutions for how to deal with variety and complexity of military SoS and their relationships. In order to successfully and effectively support defence capability development, Model-Based Systems Engineering (MBSE) should address this challenging engineering issue and provide adequate methods and solutions, in particular in conceptual design of force and capabilities. Based on SoS Thinking, this presentation explores these complicated relationships together with variety of military SoS, and examines why and where those existing engineering and architectural approaches experience and encounter problems and difficulties. Through introducing a range of SoS concepts, including types and categories of SoS, relationship reference models of military SoS, design process and SoS development states, the presentation also shares insights with the community in relation to how to capture, represent and manage various relationships of military SoS in different contexts for different purposes. SoS Thinking-based SoS relationships modelling and management is intended to help communities of researchers, developers and stakeholders in: 1) establishing better understandings and management in contexts and complexity of military SoS and their relations to uncertainties and disagreements; 2) improving ability in identification and assessments of gaps and holes in SoS development; and 3) use of a shared foundation for relevant disciplines and activities to develop adequate methods, metrics and solutions for different military SoS.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
32 About Dr Pin Chen Dr Pin Chen is a Senior Scientist with the Joint Operations & Analysis Division (JOAD) of DSTO, and led research tasks in architecture practice study for Defence, Systems Engineering for System-of-Systems (SoS), defence architecture information model development and multiple unmanned systems cooperation for mission systems. His current research interests are focused on a number of areas, including SoS Thinking, SoS engineering practice, complex systems design, force-level modelling and design, complexity management, force and capability integration, analysis and evaluation of integrated force and capabilities. About Dr Mark Unewisse Dr Mark Unewisse is a Principle Research Scientist with the Land Division of DSTO, leading the Land Capability Integration program. His 28 year career with Defence has spanned: submarine and surface ship simulation systems; infrared optoelectronic systems; Land force C2 systems; military experimentation; Army aviation; Land Joint fires; combat vehicle systems; Land network centric warfare; force-level integration; force protection; and supporting RAAF Combat Support Group. In addition, Mark has undertaken a wide range of corporate and leadership roles within DSTO. Mark’s current research efforts include: SoS integration, SoS engineering practice, tactical land ISTAR and the implementation of networked force and capabilities.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
33
10. Modelling an Expeditionary Airbase Capability system Stephen Passmore DSTO Alan Smeaton Clarity Concepts Pty Ltd Strategic Guidance The four principal tasks that the Government expects the Australian Defence Force (ADF) to be able to do are detailed, in priority order in Chapter 3 of the Defence White Paper 2013 are: • Principal Task One: deter and defeat armed attacks on Australia; • Principal Task Two: contribute to stability and security in the South Pacific and Timor-Leste; • Principal Task Three: contribute to military contingencies in the Indo-Pacific region, with priority given to Southeast Asia; and • Principal Task Four: contribute to military contingencies in support of global security. The ability of the ADF to be able to undertake these tasks relies on its capacity to undertake expeditionary force operations, defined in this presentation as ADF operations conducted and generating effects beyond Australia’s national borders, as would be the case if the ADF was required to execute any one of its four principal tasks. The ability to employ air power is a key capability in joint operations across the full spectrum of the four principle tasks assigned to it by Government. This requires a combination of multiple expeditionary airbases, the characteristics of which are shaped by the particular activities required for each mission, and the operational environment.
Evolution of expeditionary airbase Capability The ADF has operated expeditionary airbases from as early as 1917, when the Australian Army Flying Corps operated biplane fighters and light bombers from expeditionary airbases in locations within what was then called Palestine. Between then and now there has been a continuing requirement for access to expeditionary airbases, including more recently, ADF peacekeeping and multinational operations in Namibia, Cambodia, the Sinai, East Timor, Bougainville, Iraq, the Solomon Islands, and Afghanistan. The physical instantiations of expeditionary airbases arising from contemporary operational concepts such as ‘Bare Bases’, ‘Forward operating bases’, ‘Forward Arming and Refuelling Points (FARPs)’ and ‘Amphibious Assault Ships (LHDs)’ indicate some of the diversity of expeditionary airbases. Combinations of these expeditionary airbases operating in concert with each other and their supported and supporting capability systems, as might be expected in a joint task force operation, represents an Expeditionary Airbase Capability system. The need to develop a model of an Expeditionary Airbase Capability system Although an Expeditionary Airbase Capability system is implied by the physical instances above, this is not underpinned by a formal definition of the capability system. It appears to work in practice due to the concerted efforts of defence capability managers and ADF commanders at the strategic, operational and tactical levels, rather than by a deliberate design or a desire to identify capability gaps and interface issues. Simply put – “We know it works in practice, but will it work in theory?” Without a theoretical framework underpinning the capability design, can it reach its full potential?
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
34 The evolution of increasingly sophisticated and diverse air power platforms used to support the conduct of expeditionary or contingency response operations, together with a flexible and adaptable approach to force design needs to be matched by a deliberate approach to designing an increasingly sophisticated diverse and flexible Expeditionary Airbase Capability system. Model based approaches support conceptual development of capability systems through their ability to capture and share conceptual ideas in a logical framework. A model based approach to Expeditionary Airbase Capability system conceptual design requires a model that: • Captures the requirements for the Expeditionary Airbase Capability system including its supported and supporting capability systems; • Incorporates a high level abstract logical model; and, • Identifies the interface and integration risks and issues that arise from the close interdependency between the Expeditionary Airbase Capability system and the set of other capability systems that support the conduct of operational activities undertaken within and from the Expeditionary Airbase Capability system. Aims of the presentation This presentation aims to: 1. Demonstrate how a Model Based Systems Engineering (MBSE) approach may be used to: • Develop a model of the Expeditionary Airbase Capability system, based on the assumption that the Expeditionary Airbase Capability system shares functions in common with the physical instantiations of airbases listed above. • Define the ADF Expeditionary Airbase Capability system as a high level logical model; and
• Conduct a preliminary operational scenario based analysis of the interface management and integration risks and issues that exist not only between the different types of expeditionary airbases that have emerged as physical instantiations, but also between the Expeditionary Airbase Capability system and all the closely related capability systems that support it, or that are supported by it. 2. Advance the hypothesis that there is a need to highlight the internal and external interface and integration issues that arise, not just because of the increasingly diverse and sophisticated systems operating from and in support of the expeditionary airbase capability system, but also because of the potential opportunities for flexible force design and ‘plug and play’ resilience that exploring the hypothesis offers.
Reference 1 Available on–line from: . Last reviewed on 29 August 2013.
About Stephen Passmore Stephen Passmore graduated as a B.Eng (Mech) in 1983 and is currently completing a M.Eng degree in Systems Engineering. He joined DSTO in 1966 as an apprentice before pursuing a career in engineering. He now applies systems engineering approaches such as MBSE to support analysis of large scale systems, specialising in ISTAR and C2 systems for the land force. He recently managed a study program examining Airbase command and control and force protection systems. About Alan Smeaton Alan Smeaton is professional analyst with qualifications and experience in applied engineering, management and systems analysis.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
35 He was commissioned as an Australian Army officer in 1978, and has held appointments in Australian Army Engineer construction, combat engineering units. His non-corps postings have included appointments as operations officer at Defence Centre Sydney, and an appointment as a military engineering subject matter expert at DSTO Land Operations Division. Alan completed undergraduate studies through the University of New England and was awarded a Bachelor of Professional Studies in 1999. In 2002 Alan terminated his full-time Army career and embarked in a career as private sector consultant specialising in Australian Defence capability definition. Over the past decade he has led or contributed to a diverse range of operational analyses and related work that has involved participation in the preparation of capability development documentation to support a range of Australian Defence capability projects that have included: Joint Counter Improvised Explosives project; the Land Combat Vehicle System project, and the project to replace or enhance the RBS-70 ground–based air defence system.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
36
11. Model-Based Systems Engineering for Capability Enhancement of Systems of Systems Nicola Broderick DSTO Michael Waite Aerospace Concepts Pty Ltd Matthew Tetlow Aerospace Concepts Pty Ltd Complexity of operational and tactical level planning in the Defence environment necessitates a holistic modelling approach. This ensures that critical existing elements and any new requirements associated with a particular system are encapsulated and maintained with a sufficient level of detail. Increasingly complex and expensive systems are being procured by Defence which require additional consideration of their integration with existing capabilities. This presentation will detail (using an example case study) the application of Model-Based Systems Engineering (MBSE) for capability enhancement of a complex, “acknowledged” System of Systems (SoS): Acknowledged SoS have recognised objectives, a designated manager, and resources for the SoS; however, the constituent systems retain their independent ownership, objectives, funding, as well as development and sustainment approaches. Changes in the systems are based on collaboration between the SoS and the system1. The Defence Science and Technology Organisation has undertaken the Mission Success Prediction Capability (MSPC) project to enhance operational and tactical level planning, providing greater insight to decision makers during the process. This is not currently seen as
an acknowledged SoS, but its complexity and current state show that individual systems have been acquired and are maintained separately. This capability could not operate in any other category because of the Defence environment and the history of how the systems have been acquired and are currently managed. The challenge for MSPC within this operational and tactical level planning SoS is to integrate data from the already available systems and provide new capability enhancements (systems) where required. MSPC employs an MBSE approach to introduce this new capability into the already complex SoS to ensure that traceability is maintained to the stakeholder needs and the solution is robust within those boundaries. As MSPC is an enhancement to the already existing operational and tactical level planning system, the project involves not only the design of the mission success prediction “tool”, but also, and more significantly, a detailed understanding of the interfaces involved, and how the tool fits into the existing system and operational environments. This innovative approach is where MBSE is able to produce a rigorous and robust model of the interfaces and their associated characteristics while allowing for the engineering design process. This model is reinforced with traceability back to the original stakeholder needs and constraints. The difference between capability enhancement and capability/system development necessitates the more rigorous modelling approach provided by MBSE. A capability enhancement requires knowledge of the whole SoS and maintenance of that knowledge as the systems evolve; whereas capability/system development does not necessarily account for the interfaces of the entire SoS, but focuses on the single entity under acquisition. The knowledge model created during an MBSE project allows complete capture of the
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
37 SoS (nodes, linkages, data flow) in its evolving state, plus the enhancements required to meet stakeholder needs. MSPC uses an innovative MBSE approach and engineering design process to provide Defence with a robust and adaptable requirements definition; ensuring that any proposed capability enhancements to operational and tactical level planning are based on sound science, traceable to specific operator needs.
Reference 1 Dahmann, J.S. et al. 2008. Systems Engineering for Capabilities, CrossTalk: The Journal of Defense Software Engineering, Nov 08.
About Nicola Broderick Nicola joined DSTO in 2002 after completing her Bachelor of Science (Geoinformatics, Operations Research) at the University of South Australia. During her first working years she completed a first class honours degree through UniSA and her PhD through Flinders University with thesis entitled “Tactical Imagery and Geospatial Data Options for Automatic Target Acquisition”. So began her career in strategic, operational and tactical level planning research and development, which is still her passion. Nicola has also had the privilege of supporting various ADF operational units throughout Australia and overseas as an Operations Analyst. She is personally motivated to support her clients to ensure the ADF has the best capability possible to meeting the needs of the Government of Australia and its people.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
38
12. A study of a model-centric practice across the acquisition boundary Quoc Do DASI, UniSA Stephen Cook UniSA Systems engineering practice is progressively migrating to Model-Based Systems Engineering (MBSE) practice as evidenced through the contributions to the literature, the INCOSE MBSE International Workshop, and the MBSE Symposium series in Australia. In Australia various organisations such as DSTO [1], Deep Blue Tech [2], Air Warfare Destroyer [3], Aerospace Concepts [4], Raytheon [5], DSIC [6, 7] are active in MBSE research and an area of particular focus is in the definition of the systems problem and context using the Whole-System Analytical Framework (WSAF). A good deal of work has been performed done on capability definition for complex defence projects has been performed using this framework that concentrates on front-end operational and mission analysis to elicit, derive, and manage system needs and requirements, and to hold them within a model. These WSAF models possess the key feature that they hold all the information needed to automatically generate the key Capability Definition Documents (CDD) documents: the Operational Concept Description, the Function and Performance Specification, and the Test Concept Document [8, 9]. A number of new, substantial Australian Major Capital Equipment Projects (e.g. SEA 1000, LAND 400, and LAND 19, Phase 7) are adopting the WSAF approach for their capability definition work.
One of the key impediments to the expansion of MBSE across the lifecycle, particularly in competitive tendering environments, is the reliance by all parties on the use of documents to define the contractual interface between the acquirer and the supplier. As the result, the acquiring organisation develops a capability system model but has to also produce the CDD set and other related artefacts in document form. The potential suppliers then interrogate these documents to design and produce their own system models. This paper describes the findings from a collaborative research project between the University of South Australia (UniSA), the Defence Systems Innovation Centre (DSIC), and the Defence Science Technology Organisation (DSTO), that employs the WSAF approach to pass the capability system model through the contractual interface and have the supplier use this for the basis of their tender response and subsequent systems development. The project adopts a “role-play” approach, where DSTO acts as the acquirer organisation, producing an RFT model, and UniSA and DSIC play the role of a supplier organisation, developing the tender response in the form of a model. The project uses a ground-based air missile defence system as a case study. The paper surfaces key issues and challenges inherent in utilising this MBSE approach across the contractual boundary and discusses how well the selected approach deals with these and to what extent it can support the transition of the engineering aspects of the system acquisition process from a document-centric to a model-centric practice. Future work involving using the WSAF approach to support model-centric tender elevation and negotiation will be described, and preliminary findings discussed.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
39 References 1. Robinson, K., et al. “Demonstrating Model-Based Systems Engineering for Specifying Complex Capability” Systems Engineering Test and Evaluation (SETE 10). 2010. Adelaide, Australia. 2. Pearce, P., “Model-Based Systems Engineering and Its Application to Submarine Design”, Submarine Institute of Australia Science, Technology and Engineering Conference 2011, Adelaide, Australia.
capability development, acquisition modernisation, and theoretical frameworks to support the coherent teaching of systems engineering. Prof Cook is an INCOSE Fellow and Past President of the Systems Engineering Society of Australia.
3. Mays, R., “Deploying a SysML MBSE Environment - Lessons Learned from the SEA 4000 - Air Warfare Destroyer Program”, DSTO MBSE Symposium 2011, Adelaide, Australia. 4. Harvey, D., et al., “Document the Model, Don’t Model the Document”, INCOSE International Symposium 2012, Rome, Italy. 5. Saunders, S., “Does a Model Based Systems Engineering Approach Provide Real Program Savings? - Lessons Learnt”, DSTO MBSE Symposium 2011, Adelaide, Australia. 6. Ryan, M., S. Cook, and W. Scott, “Application of MBSE to Requirements Engineering—Research Challenges”, Systems Engineering Test and Evaluation (SETE 13), 2013, Canberra, Australia. 7. Do, Q., et al., “Requirements for a Metamodel to Facilitate Knowledge Sharing between Project Stakeholders”, Conference on Systems Engineering Research (CSER 2012), 2012, Missouri, USA. 8. Robinson, K. and D. Graham, “An Improved Methodology for Analysis of Complex Capability”, Systems Engineering Tests and Evaluations (SETE 10), 2010, Adelaide, Australia. 9. Do, Q. and S. Cook, “An MBSE Case Study and Research Challenges”, INCOSE International Symposium 2012, Rome, Italy.
About Stephen Cook Stephen Cook PhD is the Professor of Systems Engineering at the University of South Australia and the Technical Director – Systems Engineering at the Defence Systems Innovation Centre. He has had a varied career that commenced with over ten years’ engineering experience in the telecommunications and aerospace industry after which he joined the Defence Science and Technology Organisation (DSTO) rising to Research Leader Military Information Networks in 1994. Since 1997 he has been with the University of South Australia where he has led a variety of research concentrations in systems engineering and has pursued a wide span of research interests including systems modelling, systems engineering of C2 systems, systems approaches for defence
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
40
13. Analysis of military systems using a model-based methodology Frank Lui DSTO Michael Harris DSTO Stephen Passmore DSTO A methodology to analyse complex sociotechnical military systems has been developed, combining a model-based process for system description with operational analysis techniques for assessing the impact of system design options. This methodology was found useful for investigating such systems for military clients who do not have a definable problem with their existing system, but do want to understand the impact on a deployed force’s operations if the architecture of the subject system is changed. The changes to the architecture can arise from a deliberate attempt to improve the output, in response to altered resources, or to incorporate new capabilities and sub-systems. It was found that a structured database provided the means to capture, maintain and represent the knowledge of the system; and to facilitate problem definition and analysis in collaboration with the client. Initially, an understanding of the subject system was represented in DoDAF-complaint system architectural views, namely OV-1 (overall view) through to OV-5 (activity models). A selection of these DoDAF views was also used to represent the concept of military operations relevant to the subject system, supported by doctrine, standard operating procedures, concept-of-operation documents, and input from subject-matter experts. This data set allows operational analysts to view the system holistically and perform capabilityanalysis and gap-analysis of the sub-systems.
This presentation will discuss the evolution of this methodology through its application to two earlier studies, highlighting some of the lessons learned. Application of this methodology to future studies on Land Tactical ISTAR (Intelligence Surveillance Target Acquisition Reconnaissance) will also be considered.
About Frank Lui Frank Lui completed his PhD at the Department of Communication and Electrical Engineering, New South Wales University in 1992. He joined DSTO in 1993 as a research scientist. His early research area included the application of intelligent agents in computer wargame simulations and the use of unmanned systems in military environments. Since 2007, he has been part of a team in Land Operations Division (now Land Division), DSTO, looking into adopting system engineering and architecture frameworks for analysing military systems and operations. About Michael Harris Michael Harris has been a watchmaker, an army officer, an electronic systems R&D manager and a vehicle test manager in defence industries, and an academic at a systems engineering research centre. He joined the Defence Science and Technology Organisation in 2009, continuing his research interests in defence systems. About Stephen Passmore Stephen Passmore graduated as a B.Eng (Mech) in 1983 and is currently completing a M.Eng degree in Systems Engineering. He joined DSTO in 1966 as an apprentice before pursuing a career in engineering. He now applies systems engineering approaches such as MBSE to support analysis of large-scale systems, specialising in ISTAR and C2 systems for the land force. He recently managed a study program examining airbase command-andcontrol and force-protection systems.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
41
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
42
14. Application of MBSE tools and techniques to elicit and analyse weapon system modelling, simulation and analysis requirements
Figure 1 Summary of MS&A requirements elicitation and analysis process
Amelia Eggerking DSTO Wayne Power DSTO Model Based Systems Engineering (MBSE) tools and techniques have proven useful throughout many different phases of the capability development lifecycle including conceptual design [ i], requirements and needs elicitation [ii ] [ iii], and system design [ iv]. MBSE techniques have also been innovatively applied to help derive modelling, simulation and analysis (MS&A) requirements [v ] [ vi]. This presentation will describe the latest application of the Wholeof-System Analytical Framework (WSAF) and the resulting evolution of the methodology. The presentation will describe the process used to determine the MS&A requirements, as summarised in Figure 1, and explain how the MBSE tools and techniques were employed to support and enhance this process.
• study questions that address the client’s area of interest; • an Operational Activity model of the kill chain; • Measures of Performance (MOPs) associated with the activities of interest in the kill chain; and, • identification of MOPs required to address study questions.
The process described in Figure 1 consists of a few key steps which are typical of common systems engineering practice: requirements elicitation, gap analysis and solution development. The authors have taken a pragmatic approach in this process by proposing possible modifications to the client’s study requirements prior to proposing more costly (to development cost and/or schedule) changes to the modelling and simulation (M&S) solution.
Once the client’s study requirements have been defined an M&S solution is proposed, based on the integration of available data and existing models into a common simulation framework. This solution represents the most cost effective option available to the analyst in terms of design and development effort, and is treated as the baseline M&S solution. In defining this M&S baseline the analyst will identify which executable models will be used to perform each activity in the kill chain.
High level client requirements are captured through the following classes of information and their relationships:
A gap analysis is then performed to determine whether the baseline M&S solution is fitfor-purpose to satisfy the client’s study
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
43 requirements. If the baseline M&S solution is judged to be fit-for-purpose then “modelling for the sake of modelling” is avoided. However, if the gap analysis shows that the baseline solution cannot satisfy all, or a subset of, the client’s study requirements, then more work is required before the M&S solution can be implemented. There are a number of reasons why the baseline M&S solution may not be suitable to satisfy the client’s study requirements (i.e. the identified MOPs cannot be measured), including: • the models that comprise the baseline M&S solution may not be of sufficient fidelity; or, • desired functionality may not exist in the current models. There are two options at this point – either the client’s study requirements can be revised (by identifying alternate MOPs which can actually be measured with the baseline M&S solution) or the proposed M&S solution can be modified (by identifying system or subsystem models which require further development). It is suggested that
Figure 1
revision of the client’s study requirements should be considered first as it is the more cost effective of the two options, noting that any changes to the study requirements must have the client’s approval. Once the client is satisfied with the proposed MS&A approach (M&S solution and the MOPs being measured for each question) then the solution can be implemented. By applying the latest evolution of the WSAF MBSE approach to MS&A requirements elicitation and analysis, the authors were able to develop a fit-for-purpose MS&A capability. The benefits of approaching a weapon system performance task using the MBSE tools and techniques described in this presentation include: • efficiency in satisfying client study requirements, by avoiding “modelling for the sake of modelling”; and, • improved rigour of the approach – lending credibility to the MS&A approach by clearly demonstrating traceability from client study requirements to proposed M&S solution
OV-1 for Anti-Ship Missile Defence Example
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
44 and providing a clear method for expressing limitations of and justification for the modelling employed (fitness-for-purpose). This presentation describes the latest evolution of the WSAF through a readily understandable example – developing MS&A requirements for assessing the performance of an anti-ship missile defence system (see Figure 2).
References i. Mordecai, Y. et. al. Conceptual Modelling of PhysicalInformatical Essence Duality of Cyber-Physical Entities, IEEE 2013. http://esml.iem.technion.ac.il/site/wp-content/ uploads/2011/07/PID2891257.pdf ii . Tramoundanis, D. et. al. An Improved Methodology for Analysis of Complex Capability, Presented at Systems Engineering / Test and Evaluation conference 2012
About Amelia Eggerking Amelia Eggerking joined DSTO in 2006 after graduating from the University of Sydney with first-class honours in Mechatronics (Space) Engineering. She works in Missile Modelling, Simulation and Analysis Group in DSTO’s Weapons and Countermeasures Division (WCMD). In her role she develops mathematical models of weapons systems to support ADF acquisitions and test and evaluation activities. Over the past seven years she has developed skills in conceptual modelling, system model design and development, and weapon system performance analysis. In 2012 she was awarded a Defence Science Fellowship to work with the US Navy as part of the P-8 Poseidon’s weapon-stores integration team. She also had the privilege of deploying in support of ADF operations as an Operational Analyst in 2011.
iii. Tramoundanis, D. et. al. Adapting to accelerated acquisition: WSAF in LAND 19 Phase 7, Presented at Land Warfare Conference 2010 iv. Estefan, J. Survey of Model-Based Systems Engineering (MBSE) Methodologies, INCOSE MBSE Initiative, 2008 http://pdf.aminer.org/000/260/416/towards_a_unified_ paradigm_for_verification_and_validation_of_systems.pdf v. Robinson, K. et. al. An Improved Methodology for Analysis of Complex Capability, Presented at Systems Engineering / Test and Evaluation conference 2010 vi. Demediuk, S. et. al. Using MBSE to Understand the Link between Capability Acquisition Projects and DSTO Technology Advice, Model Based Systems Engineering Symposium, 2012
About Wayne Power Wayne Power graduated with honours from the Queensland University of Technology (QUT) with a Bachelor of Engineering (Aerospace Avionics), minor in Systems Engineering. He has spent the last seven years working in Weapons Capability Analysis within DSTO’s Weapons and Countermeasures Division (WCMD). His work in WCMD has included weapon system integration modelling and analysis, and researching and developing the Whole-of-System Analytical Framework (WSAF). The WSAF employs a ModelBased Systems Engineering approach for the provision of cross-Defence modelling, simulation, analysis and Capability Development activities.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
45
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
46
Workshops 1. Structured approach to concept development George Strengers BAE Systems Not available at time of print.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
47
2. How can MBSE capture user perspectives of complex capability needs? Michele Knight DSTO Les Vencel VCORP Consulting Pty Ltd As enterprise architects and systems engineers, we need to communicate with stakeholders at multiple stages of the conceptual design process. We often need to deal with complex socio-technical systems, where there are multiple valid perspectives and no single right answer [1]. This workshop is seeking your ideas for how Model-Based Systems Engineering (MBSE) tools and techniques can be used to support stakeholder engagement, especially in relation to complex systems. The workshop facilitators are from a part of DSTO that helps Defence make better use of its sensor data, analysis and reporting tools, by exploring options for integrating them. In the past, we would capture user inputs on a whiteboard, then document our notes in Word, PowerPoint or Excel and send them back to the users for review. Sometimes we’d produce Enterprise Architecture views - but these needed to be exported into Word or PowerPoint for review.
This workshop will consider how we can use MBSE tools and techniques to capture, analyse and synthesise stakeholder inputs – especially for complex situations. This might involve capturing the following types of inputs and relating them to the system design: a) Rich Pictures [2] or ‘mud-maps’ of complex systems b) Mission Threads or workflows [3] and the interactions between them c) User expectations, issues and feedback. Workshop participants will be invited to brainstorm ideas and to share their experiences of using MBSE to support communication with stakeholders (especially when dealing with complex situations). In addition to discussing the tangible benefits of an MBSE approach, the workshop will seek to identify any relevant limitations and workarounds with currentgeneration MBSE tools.
References [1] See for example http://en.wikipedia.org/wiki/Cynefin or Snowden, D. J., & Boone, M. E. “A leader’s framework for decision making”. Harvard Business Review, 85(11) (2007), 68 [2] See for example http://en.wikipedia.org/wiki/Rich_picture or Checkland, Peter B. “Systems Thinking, Systems Practice”, John Wiley & Sons Ltd. (1981, 1998). [3] See for example http://en.wikipedia.org/wiki/Workflow or M. Gagliardi, W. Wood, and T. Morrow, “Introduction to the Mission Thread Workshop”, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-2013-TR-003, 2013. http://resources.sei.cmu.edu/ library/asset-view.cfm?AssetID=63148
We’ve recently obtained access to an MBSE tool and we believe it should be possible to use MBSE techniques to provide: - Methods for capturing user inputs - An audit trail of user feedback and - Traceability of the rationale behind system design decisions.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
48 About Michele Knight Michele Knight has more than twenty years experience at DSTO. The main focus of her work is in applying systems engineering and operational analysis techniques to the study of Defence Intelligence, Surveillance and Reconnaissance (ISR) systems. Michele currently works in DSTO’s National Security and ISR Division where she supports a range of initiatives related to the integration of ISR systems. Michele has a Bachelor of Electrical & Electronic Engineering from the University of Western Australia, a postgraduate Diploma in Technology Management from Deakin University and a Master of Science in Defence Operations Research from the University of New South Wales at the Australian Defence Force Academy. About Les Vencel Les Vencel has over thirty years experience in the engineering and management of Defence systems projects, both from within the government as well as in industry. He is the principal systems consultant and director of VCORP Consulting Pty Ltd. His prior experience comprises senior engineering and management roles in industry and Defence, including General Manager of the Radar Systems division of GEC Marconi Systems, senior manager on Australia’s Jindalee Over the Horizon Radar Network (JORN) radar program and over 15 years experience in the Defence Science and Technology Organisation. At DSTO, he was primarily involved in radar and avionics systems for the F/A-18 and the F-111C. His last position prior to leaving the DSTO was Head of the Hornet Radar Systems Group. Mr. Vencel’s primary work interests are the application of systems engineering to complex and evolutionary programs. He has degrees in Mathematical Science and Electrical Engineering from the University of Adelaide and is working towards a doctorate in Systems Engineering.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
Conference Secretariat
Lisa Beckham Tel: +61 8 8274 6044 Fax: +61 8 8274 6000 Email:
[email protected] Web: www.sapmea.asn.au/ase2013
Disclaimer
Every effort has been made to present as accurately as possible, all the information contained in this brochure. The Organising Committee, SAPMEA Incorporated and its Agents act only to procure and arrange these activities and do not accept responsibility for any act or omission on the part of the service providers. No liability is accepted for any inaccuracy or misdescription nor for delay or damage, including personal injury or death, howsoever caused resulting from or arising out of reliance upon any general or specific information published in this brochure. In the event of unforeseen circumstances, the Organising Committee reserves the right to change any or all of these details. Conference Organisers will accept no liability for personal injury/ies or medical expenses, or for loss/damage to property belonging to Conference participants or accompanying persons, cancellations or industrial disputes etc either at the time of or as a result of the Conference or during all or any tours and events or their stay in Adelaide. Participants are strongly recommended to arrange their own insurance cover for health and accident, lost luggage and travel cancellation/s. For sapmea’s full Privacy Statement please go to our website.
Endorsed by The Systems Engineering Society of Australia (SESA) and The Australian Chapter of the International Council of Systems Engineering (INCOSE)
Appendix 1.
A STRUCTURE FOR MODEL BASED CONCEPT DEFINITION George Strengers BAE Systems, Williamstown Victoria
A short time-to-market, or analogously, a short timeto-bid for competitive tenders, is often crucial for successful Concept Development and yet these short timescales fit incongruously with a typical Systems Engineering approach which aims to “front-load” engineering activities with analysis and attendant attention to careful decision making. It is the ardent desire of Systems Engineers to find means of applying Systems Engineering approaches to the intense and brief early Concept Development phase of the system lifecycle in order to create high quality concepts without imposing delays on critical timelines.
1. Introduction This paper was developed from work accomplished within the INCOSE Model Based Concept Development Working group in 2013. The paper presents an underlying structure for Concept Development and in doing so, highlights the methods that may be employed by processes and tools when applying Model Based Concept Development (MBCD). The structure is expressed in terms of a controlled vocabulary defining a dictionary for things involved in MBCD.
2. Concept Development This paper considers that Concept Development covers all of the topics identified in the INCOSE Handbook related to the early Concept Development phases of a system lifecycle which can be précised as: • • •
• •
The Concept Development phase should capture divergent thinking by modeling technical, operational and business information across all system lifecycle phases. Thus Concept Development phase must model and analyse: •
Gathering knowledge of a problem situation and methods of solving the problem Eliciting the needs of parties involved in the problem situation Translating needs into clear requirements statements including criteria for measuring success Developing optional candidate solutions to the problem Assessing the feasibility of the best candidate solution
• • •
the Concept Development Phase itself and carefully assess the Agreed Candidate Concept the Design & Development Phase the Deployment Phase possibly the Disposal Phase
A further feature of divergent thinking is that Concept Development should envisage many solutions to a problem and therefore MBCD must accommodate the ability to model numerous Candidate Concepts before evaluating an Agreed Candidate Concept.
To develop concepts with a high probability of success there needs to be a strong and necessary link between a good business case and the technical description if a concept. Therefore Concept Development must involve and integrate both business and technical aspects of a concept.
Two sources of previous work on systems engineering taxonomies are used by this paper as points of reference for eliciting a structure for effective MBCD. The first point of reference is the concept model for systems engineering developed by Oliver et al [1] which was extended in order to
1
better express Model Based Systems Engineering (MBSE) terminology. The second point of reference was James Martin’s [2] Seven Samurai systems used to describe the development lifecycle of a system. This second model was also extended in order to allow focus on the Concept Development phase of a system lifecycle.
Development Phase within a system lifecycle by introducing development of Concept Intervention Systems and Concept Realization Systems and establishing an Agreed Concept System before embarking on the development of an Intervention System and Realization Systems in later phases of design. MBCD applies tool-based methods to develop models of Concept Intervention Systems and Concept Realization Systems and facilitates down-selection to an Agreed Concept System.
Figure 1 shows an expansion of Martin’s [2] seven system ontology to embrace the Concept
SYSTEM LIFE CYCLE VIEWS 1.Context and Problem Analysis Phase Martin’s Lifecycle[1]
2.
Design & Development Phase Intervention System and Realization System
Context and Problem
Concept Development Phase
Extended Lifecycle
1.Context and Problem Analysis Phase Context and Problem Analysis
2. Candidate Concept Phase Concept Interventions Systems and Concept Realization Systems
3. Agreed Concept Phase Agreed Concept
Design & Development Phase 4. Design & Development Phase Intervention System and Realization System
3. Deployment Phase
Deployed system in new Context (including Collaborating, Challenging and Support Systems)
Deployment Phase 5. Deployment Phase
Deployed system in new Context (including collaborating, challenging and support systems)
Figure 1. System Life-Cycle views
Three classes of model need to be used in MBCD in order to fully describe the business and technical aspects of a concept; these are:
3. Concept Models 3.1. Models and Views Architecting methods are commonly used to represent concepts and creating many architecture views to represent aspects of the system that are meaningful to many stakeholders and users of the architecture. Model Based methods seek to use toolbased applications to develop models which either directly generate architecture views of a system or provide significant inputs to the synthesis of architecture views.
a. b.
c.
Organizational Models which describe the system Domain and Stakeholders. Operational Models which describe the interactions and activity of Stakeholders, the environment and systems. System models to describe system features, elements and requirements.
3.2. Concept Model Span In order to fully analyze the extent of a problemspace, a suite of Organizational, Operational and
2
the field for the Intervention System. Concept Development will typically undertake preliminary operational modeling of the Intervention System. Operational Modeling methods may also be applied to the operation of Realization Systems needed in order to create the Intervention System.
System Models is needed and they should span the period from the perceptions of the problem, through a development phase and culminating in a Deployed System and an associated Support System. Similar time span should be considered for models of the Intervention System and Realization Systems but the Realization System lifecycle typically concludes when the Deployed System commences operations in the field.
Concept Operational Modeling must include in their scope the system of interest as well as cooperating systems, support systems, competing systems and other interactions in the operational environment. The time span of Concept Operational Models must accommodate views to analyze the problem as it “was” and how the problem situation “is” state has changed as a result of the imposition of the Deployed System.
Analysis of the concept is greatly benefitted if Concept Models are structured to embrace both business aspects and technical aspects of a concept. Whereas systems engineers and associated analysts typically focus on technical aspects of a concept by developing Operational Views and System Views mainly depicting the Intervention System. Attention is also needed on the motivations and needs of a project and these factors must be represented in Organizational Views.
3.5. Concept System Models Concept System Modeling and associated views address how tangible system elements are combined to offer solutions to a problem. Concept Development will typically undertake preliminary system modeling of the Intervention System and preliminary system modeling of the Realization System.
The time constraints imposed on Concept Development dictate that Concept Models must be concise and focused on understanding the scope, costs and risks associated with one or more Candidate Concepts.
The nature of Concept System Models is typically that of physical element models, functional flow models and views such as DODAF SVs. A key feature of Concept System Models is that they include decomposition into subsystems in a fashion that will promote elicitation of acquirable subsystems provided by suppliers or in-house design teams.
3.3. Concept Organizational Models Organizational Models and associated views capture the goals, visions and motivations of organizations and stakeholders operating within a broad environment. The nature of views associated with the Concept Organizational Modeling is that they may be: •
• •
4. Concept Models of Stakeholder Need In a model-based paradigm, Concept Organizational Modeling, Concept Operational Modeling and Concept System Modeling should be structured to explicitly capture Stakeholder Needs. The full range of stakeholders can be obtained by considering all phases of a project from the Concept Development Phase to the Deployment phase. Typically, the Concept Development phase must evaluate the likely stakeholders starting with the Concept Development phase itself and including likely
very much text-based derived from extant enterprise management reference documents. Based on business process models Based on highly unstructured formats such as “Rich Pictures” derived from techniques such as Soft System Methodology
3.4. Concept Operational Models Concept Operational Modeling and associated views focus on those attributes that describe operations in
stakeholders for succeeding phases. Figure 2.
3
4.2. Operational Stakeholder Needs Stakeholder Needs in Concept Operational Models must quantify the nature of the problem and offer means to measure the extent of the problem or the efficacy of the solution. Typically, Measures of Success (MOS), Measures or Effectiveness (MOE) are developed pertaining to operations in the field.
Stakeholders across Project Phases illustrates how a wide spectrum of Stakeholders may be identified by considering the full lifecycle of a system. A disposal phase may also be considered. Sufficient Organization, Operational and System models are needed to cover all likely stakeholders and their needs. Concept Lifecycle Phase Acquirer Supplier Developer
Design/Develop Lifecycle Phase Developer Regulators Subcontractors Laws
A key feature of Operational Concept Models is that they must be explicitly related to the goals, visions and motivation elicited in the Concept Organizational Models. In a model-based paradigm, the MOE/MOSs included within Concept Operational Models must have clear linkages to goals and objectives contained within the Concept Organizational Models.
Deploy Lifecycle Phase Owner User Support Competitor/threat Collaborator Regulator Public Laws and regulation
Figure 2. Stakeholders across Project Phases
Operational analysis is a classic means of elucidating elements of a problems space and articulating MOE/MOSs. In a model-based paradigm, the operational models should be the source of operational analysis outcomes.
4.1. Organization Stakeholder Needs Concept Organizational Models may express Stakeholder Needs in terms of goals and motives that are broader than the problem under study and these broad objectives may have to be refined and expressed in narrower terms pertinent to a particular problem or project. For instance Acquirer objectives may initially be expressed in terms that are defence-force wide but these statements should be narrowed into project specific acquisition goals.
5. System Requirements 5.1. Concept Models of System Requirements By the time analysis, modeling and elicitation has refined and partitioned Stakeholder Needs to a system level they are typically termed “System Requirements”. Whereas Stakeholder Needs are predominantly expressed within Organizational and Operational Models in terms of broad goals and intentions, System Requirements are predominantly expressed within System Models in terms of measurable parameters. System Requirements provide a focus on the Acquirer’s viewpoint but these requirements must be further decomposed into sub-system requirements expressed in terms of measurable parameters and characteristics pertaining to acquirable subsystems in order to attain a Supplier view of the system. System Requirements elicited in the Concept Development phase are often expected to be maintained as a definitive set of System Requirements in the later Design & Development Phase.
The expression of Stakeholder Needs in Concept Organization Models must state the nature of the problem and offer means to measure the extent of the problem or the efficacy of the solution. Typically these are expressed as high level goals such as Vision Statements or business rules meaningful to a Stakeholder. Stakeholder Needs must also be refined into artefacts such as: • • •
Contracts and Agreement clauses (representing Organization and legal goals) Statements of Work (representing mandatory tasks) Work Breakdown Structure (WBS)
4
A key feature of the System Requirements is that they must be explicitly related to Stakeholder Needs contained in Concept Operational Models and in so doing maintain traces to Concept Organization Models. A model-based approach should always foster explicit linkages from Organizational Models to System Models through Operational Models.
Knowledge which resides with individual people and often springs from innovation, inspiration and creative processes. It is a challenge for MBCD to capture Implicit and Explicit knowledge in a manner that can be related to models. MBCD will typically generate new knowledge in the form of models and related views.
As well as being closely tied to models, System Requirements must be able to be articulated in textual formats suitable for use by many stakeholders. System Requirements must therefore be developed into unambiguous artefacts such as: • •
6.2. Knowledge Veracity It is important at the outset of a Concept Development to carefully manage sources of knowledge. Active knowledge exists within or in association with a model-based environment which may be readily evolved and changed by actions within the model environment – thus the true state of the knowledge resides within the model.
System and subsystem requirements specifications (technical requirements) Verification/Validation Matrix (representing acceptance criteria and processes)
Active External knowledge exists outside the modelbased environment and can be influenced by a project but requires agreement before changes may be made. An example may be a customer requirements set under review during a Concept Development contract where analysis may unearth a problem and an agreement is needed in order to alter a customer requirement. In these cases the true state of knowledge can be considered to reside beyond the model environment.
6. Models of Concept Knowledge 6.1. Sources of Concept Knowledge The extended Systems Engineering taxonomy derived from Oliver et al [1] identifies Operational Knowledge and Systems Knowledge as key factors in systems engineering in general and it may be inferred that such knowledge is also a key feature of Concept Development. An essential part of Concept Development is the utilization of knowledge from many sources. MBCD aims to use tools-based models to manage knowledge and establish relationships between many sources of knowledge.
Models of Passive knowledge may be created in order to represent important knowledge that is entirely dependent on external sources of information which cannot be influenced by the modeler or project. An example may be a model created to capture the requirements or to parse information associated with an international standard that must be observed for a project. Thus the truth resides outside the model environment and cannot be altered.
Approaches to gathering knowledge for Concept Development must include methods of capturing Explicit Knowledge which is normally in formats able to be identified, stored and managed. Moreover, methods must be in place for capturing Implicit
5
The description above highlights the need for recognizing knowledge veracity or the source of the truth during Concept Development. This situation can be further complicated when the source of truth may shift during development. Often Concept Development is an exploratory undertaking and levels of operational knowledge and system knowledge may be low at the outset. Initial development may place knowledge truth within a model but better understanding and the existence of legacy systems or use of non-development systems to solve a problem may shift truth outside the model
Body of Concept Knowledge
Organizational Models
Candidate Concept Models Invariably, the Concept Development phase must consider more than one solution option before down-selecting to a preferred solution. In many situations, one enterprise may not be able to develop solutions alone and may adopt the role of an Acquirer seeking solutions from Suppliers.
Operational Models
Active Models
Passive Models
Internal Truth
Explicit Knowledge
System Models
External Truth
Implicit Knowledge
External Truth
Implicit Knowledge
Explicit Knowledge
Explicit Knowledg External References
Figure 3 Concept Knowledge Management
6.3. Concept Multiplicity The Acquirer may develop a number of Candidate Concept options which will be expressed as Acquirer Concept Models in an MBCD environment. The Acquirer may therefore have to seek a commensurate number of Supplier Concept Models. The Concept Development phase must therefore be managed as a multidimensional space where optional Acquirer solutions and multiple solutions
environment as references or linkage to those legacy or non-development systems. MBCD must manage these various types of knowledge and manage the veracity of concept knowledge as described in
6
from suppliers quickly multiply the number of Concept Models to be managed. Therefore MBCD must accommodate high Concept Multiplicity.
against pertinent Acquirer Concept Models to confirm compliance of the Supplier Concept Model to the Acquirer Concept model. In an MBCD environment, Acquirer Concept Models will ideally be linked to Supplier Concept Models to facilitate assessment of Concept Compliance. However, provision also needs to be made for references from artefacts to models where there is no facility to share models between Acquirers and Suppliers.
6.4. Concept Consistency Each set of Concept Models pertaining to a candidate solution must allow assessment of consistency. In the MBCD environment, processes must be in place to: •
•
•
6.6. Concept Truth A further vitally important matter is the relationship between the acquirers view of the truth as compared to the supplier submissions to satisfy a tender. As discussed in the previous section on knowledge, the supplier submissions may become the external truth and Acquirer models may have to be adapted to transition from internal Acquirer truth and conform to the revised external source of truth resident in Supplier Concept Models
link Concept Organization Models to Concept Operational Models to confirm that Stakeholder needs expressed at an Organizational level are preserved as Stakeholder Needs at an Operational level. link Concept Operational Models to Concept System Models thus allowing validation of System Requirements to Operational Stakeholder Needs. Link Concept System Models to Organizational models where the latter models have a strong influence over allocation of System Requirements to subsystems.
Figure 4.illustrates the MBCD challenge of maintaining Concept Compliance and Concept Consistency in an environment of high Concept Multiplicity where Acquirer Concept Models may have to be adapted to accommodate Concept Truth resident in Suppler Concept Models.
The creation and maintenance of linkages between Concept Models is important for assuring Concept Consistency for each Candidate Concept and must be repeated on a larger scale in a high Concept Multiplicity environment.
Figure 4. Concept Multiplicity, Consistency and Compliance
6.5. Concept Compliance Each Supplier Concept Model must be assessed Supplier Viewpoint
Supplier 3 Supplier 2 Supplier 1
Concept Compliance Concept Organizational Models Acquirer Viewpoint
Option 1
Option 2
Option 3
Concept Consistency
Concept Operational Models Concept System Models
7 Concept Truth shifts from Acquirer to Supplier
7. Developing an Agreed Candidate Concept
7.2. Concept Assurance A critical process of Concept Development is the provision of careful review of Concept Compliance, Concept Consistency and Concept Strength to assure transparency to processes that culminate in selection of Agreed Concept Systems.
7.1. Concept Strength Assessments of concept strength must be made for all Candidate Concepts and comparisons of Concept Strengths are needed in order down-select an Agreed Concept Candidate from a large set of Candidate Concepts.
Concept Compliance Assurance and Concept Consistency Assurance Model Based Concept Compliance and Concept Consistency employs the establishment of links that are readily reviewable by decision makers working within a model-based environment. Similarly toolbased metrics should be developed measuring how thoroughly Concepts have been reviewed. Thus MBCD will support a high level of automated Concept Assurance on complex projects.
Concept Tallies Metrics on the simple count of candidate concept consistency linkages across the spectrum of Organizational, Operational and System models will allow an initial comparison and assessment of the more consistent Candidate Concepts. Similarly, metrics on the simple count of Candidate Concept Compliance linkages across the Acquirer and Supplier boundary will also allow an initial comparison and assessment of the more compliant Candidate Concepts.
Concept Strength Assurance Complex projects often face the daunting prospect of assessing the strength of many Candidate Concepts. Effective Concept Development should aim to afford a high level of review and transparency to decision makers of Concept Strength scoring and decisions to eliminate candidates. Model Based methods should offer robust Concept Assurance in support of final decisions to select an Agreed Candidate System by automating metrics on reviews of tallies and weighted scores. Moreover, visualization methods should be applied to simplify the task of presenting metrics on Concept Strength to decision makers.
Concept Weighted Scores A more realistic, assessment of the best Candidate Concepts is typically based on weighted scores where compliance, consistency and other factors may be given different weights or priorities in order to reflect Organizational Goals. Weighting and scores should be part of acquisition strategies incorporated into Organizational Models used to govern the Concept Development phase. Early Concept Assessment As the multiplicity of Candidate Concepts grows there is a need to quickly rule out the most unlikely Candidate Concepts. This may be done by selecting a number of key organization, operational and system characteristics of all candidate systems and assessing them quickly to eliminate the weakest candidates and focus more effort on to the assessment of the strongest candidates. An MBCD approach should establish an Early Concept Assessment model applied to all Candidate Concepts and provide a high level of transparency to allow review of early Candidate Concept elimination decisions.
8. Conclusion The following conclusion is a description of Model Based Concept Development assembled from terms (highlighted in bold) defined within the preceding paper. Model Based Concept Development (MBCD) aims to create architectural views and artefacts either generated by, or derived from, tools-based Concept Models that will enhance the productivity of the analysts and concept decision makers within a concept development team. Models of Concept Intervention Systems and Concept Realization
8
Systems are developed employing the full gamut of Organizational Modeling, Operational Modeling and System Modeling methods in order to capture the business and technical aspects of the concept.
Passive Models based on Implicit and Explicit sources of Concept Veracity. Concept Assurance is necessary in order to accomplish a true and transparent down-selection to an Agreed Candidate Concept. MBCD methods must support concept decision makers with automated and visualized Concept Compliance Assurance metrics arising from reviews of Concept Compliance and reviews of Concept Compliance Strength. Similar metrics should be generated for Concept Consistency Assurance based on reviews of Concept Consistency and Concept Consistency Strength.
The Concept Span should include all phases of the system lifecycle from problem analysis to system deployment or disposal. Time-to-market (or similarly time-to–tender) pressures dictate that Concept Models must be developed rapidly and are by necessity succinct and should contain only sufficient detail to assist with the understanding of concept scope, cost and risks. A critical feature of Concept Intervention System models and Concept Realization System models is that they provide views that capture Stakeholder Needs and System Requirements including System Requirements for subsystems.
The great challenge of applying model-based systems engineering methods to the Concept Development phase of a system lifecycle is to achieve useful modeling outcomes that support the development and assessment of a feasible concept within tight timescales.
Concept Models and methods should support the assessment of Concept Consistency for each Candidate Concept and support assessment of Concept Compliance between Acquirer Concepts and Supplier Concepts.
References 1. David Oliver, Michael Dickerson, Joseph Skipper. Semantic Dictionary and Concept Model. INCOSE INSIGHT Vol 7 Issue 2 July 2004.
Concept Multiplicity arises from the need to gain greater understanding of the problem situation and possible solutions by proposing a diversity of Concept Candidates. Concept Multiplicity also increases as Acquirer Concepts and Supplier Concepts multiply the information that must be contained in concept models.
2. James N. Martin. The Seven Samurai of Systems Engineering – Dealing with the complexity of Seven Interrelated Systems. INCOSE 2004 International Symposium.
Concept Models should support the assessment of Concept Compliance Strength and Concept Consistency Strength for each Candidate Concept. The assessment of Concept Strength should support a method for Early Concept Assessment to eliminate the weakest candidates and so allow more focus on the assessment of the strongest candidates. MBCD methods must facilitate quantitative comparisons of the Concept Strength for each Candidate Concept to allow objective down-selection to an Agreed Candidate Concept. Concept Models must incorporate well managed Concept Knowledge using Active Models and
9
