Reference Missile Functional Architecture, addressing design in a multinational Defense Company Giulio Telleschi, Andrea Caroni Ed Willingham Pierre-Henri Pradel Missile Dynamics Italy Systems Design & Validation UK System Design & Validation FR MBDA Italy MBDA UK MBDA France {giulio.telleschi, ed.willingham@mbda.co.uk pierre-henri.pradel@mbda- andrea.caroni}@mbda.it systems.com Copyright © held by the author Abstract—The need to improve design performance and  Multinational projects and international customers avoiding rework in missile systems development has lead MBDA with different cultures and understanding, adding an to set up an international team to identify a super-set of missile extra dimension to the above stated points. functionalities in any missile domain, ranging from air-to-air to anti-ship missiles. This work led to an open functional Missile functional modelling & architecture should become architecture that can be tailored for any project, with a in the future key enablers to manage the increasing complexity generalization of functional elements based on the SysML of the missile design ([1], [2]). language and MBSE approach. The Reference Missile Functional Architecture (RMFA) guides the systems architect. Taking into MBDA has set up an international team to identify a super- account the evolution of the Defense world and the multinational set of missile functionalities in any missile domain, ranging aspects related both to MBDA and its customers, the RMFA will from air-to-air to anti-ship missiles, with the goal to create a provide an open, modular, robust, interoperable and cost- reference model that comprises a superset of functions, services efficient reference for future developments. The RMFA is built and information model which can be referenced and using SysML and is constructed to have no restriction with specialized for current and future missiles. Model adoption respect to national security. The RMFA can be used as an shall reduce development risks while enabling expertise cross- appropriate framework for Knowledge Management to capture sharing and to allow for consistency across our products. and share the company know-how at group level. II. MBDA’S APPROACH TO MODEL-BASED SYSTEMS Keywords— Model-Based Systems Engineering; Reference Functional Architecture; MBSE; SysML; Defense; Missile; ENGINEERING Defense Architecture Framework. The Defense world is traditionally a driver in MBSE adoption and evolution, e.g. defining Defense Architecture I. NEEDS Framework (DAF) artefacts using templates such as US DoDAF (Department of Defense Architecture Framework, During the last decade, missile design has seen a significant [3]). A key differentiator between the commercial frameworks increase in complexity which has originated from: and DAF is in the provision of definitions and formalisms;  Computation resource increases and new high- DAF having far greater emphasis on explicitly defining terms performance and complex processing techniques has in common usage and providing supporting formalisms to led to an unprecedented demand of capabilities and provide consistency in application to aid governance. flexibility; MBDA’s strategy for Model-Based Systems Engineering  Missile interoperability - Missiles are designed for (MBSE) empowers the advantages provided by cross-sharing multiple platforms and multi-missions, leading to a and model consistency. Some examples of MBSE within the wider-ranging requirement set, Concepts of business, that are shared internationally are: Operations (ConOps) and Concepts of Use (ConUse);  MBDAAF, a legacy MBDA DAF;  More stringent safety and security constraints;  International working groups, e.g. RMFA is a delivery  Limited budget constraints forcing greater need for of one of these working groups; modularity and reuse policies together with  National Capability Teams to foster MBSE within commercial equipment adoption; each National Company (NatCo);  Legacy guidelines and procedures. Weapon and weapon systems design is usually with limited Then RMFA has to be open and evolutionary to be adapted sharing across NatCos due to restricted or classified to the future MBDA missile developments and the next information, therefore MBSE is tailored for each project- technologies insertion. specific solution. IV. RMFA PRINCIPLES III. RMFA GOALS The RMFA has been developed through an international To adopt work sharing where applicable, MBDA encourages working group with missile system design practitioners coming the use of MBSE and reference models both at missile and from UK, France and Italy. Regular meetings and weapon system level (e.g. Command & Control, [4] and [5]). collaboration from architects across the business, together with In particular, the role of the RMFA to act as a “reference” is: feedback from missile systems development, has enhanced and  To share a common taxonomy on missile functional matured the architecture. This has resulted in a single RMFA analysis; being created and adopted across projects throughout our business with our European NatCos. Introducing RMFA  To share a common way of thinking a missile benefits and driving the process the detrimental effects of functional architecture across the company; complexity within our products has been greatly reduced.  Through a methodology, which supports how to The system architecture design has to face many challenges instantiate RMFA on every specific missile project in (Fig.1): order to:  It’s a multi-viewpoint engineering activity; o Identify the required missile functional architecture;  Functions are cross-viewpoints; o Support the capture of the non-functional  At the end there is only one solution architecture viewpoints like performances, safety or which commits the product development and the security in order to select the appropriate stakeholders satisfaction; missile physical architecture;  The challenge is to make an early and robust o Elicit the equipment functional requirements validation of the solution architecture. and associated behavior and performances; Architects Viewpoint embraces the whole system and has o Avoid an excess of project-specific to manage its complexity and every specialist viewpoint. modelling, spreading within the Company a Engineering Specialists Viewpoints are derived from each common way of modelling; specific field that is analyzed and will identify the various functional allocation constraints and the non-functional o Share internationally non-restricted requirements (e.g. for performances, safety, integration, V&V, architecture design best practices. security, as in [6] and [7]). Engineering specialist feedback is  Enforce top-down MBSE at missile system design paramount to the evolution and development of the RMFA level and support the product lines initiatives; model, which is expressed within the non-functional views that enrich the model and turn it to be useful at every stage of  To enhance Knowledge Management and to capture design. When the design and selection processes are complete, and share the company expertise at group level; the solution architecture is delivered and it includes Program/Project Viewpoint and Sub-contractors viewpoints to RMFA has to encompass current and future missile manage the project and its deliveries ("viewpoint-driven" developments in all fields that are part of MBDA portfolio such method as described in [8]). as air dominance, battlefield engagement, ground based air defense and maritime superiority. The main objective of the RMFA and its joint methodology is to facilitate this multi-viewpoint architecture selection process. Fig. 1. The challenge of System Architecture Design  Generic missile System of Interest (SOI): Describes V. RMFA DEVELOPMENT the SOI which contains functions which represent a RMFA is a missile functional architecture framework superset of functionalities of which a sub set can be structured around: allocated to missile products. The SOI also contains a set of ports which represents the superset of external  Missile use cases; services;  Functional chains analysis;  Use cases: Represent the goals of the generic missile;  Missile functions;  Functional chains: Sequenced functions which  Missile Services (Interfaces); provide the system with well-defined sub capabilities;  Information/Data model;  Role-based actors: A functional role-based actor (e.g. Launcher, Fig.3) is responsible for a single functional  Missile sub-system (equipment) functions captured activity within the system. Functional role-based within functional nodes; actors allow for project specific missile models to define their physical actors through inheriting role-  Architecture Examples. based actors from RMFA. (See Role-base actor Use cases are to be tailored for each project, mainly section for more details); depending on the solution that has to be delivered (e.g.  Black-box functions: A superset of functions that maritime superiority, tailoring for an anti-ship missile). describe the missile ‘high-level’ behavior. Black-box Functional elements and functional chains will be shortlisted functions would map to the same level as traditionally for each project, according to its specific requirements and described in a missile Technical Requirements design. A particular focus is set on functional chains as they Specification (TRS); help in defining:  White-Box functions: A superset of functions that  Sub-architecture of the system architecture which, describe the missile ‘equipment level’ behavior. along with the system use cases, structure the capture White-Box functions would map to the same level as of the system functional behavior and its functions traditionally described in equipment TRS’s; decomposition;  Functional nodes: Functional nodes represent a  Identify the functional & non-functional requirements grouping of logically related behavior. Functional attached to the functions; nodes are identified in order to maximize cohesion,  Functions allocation to sub-systems will allocate minimize coupling, minimize connectivity and requirements to those sub-systems. promote reuse. Functional nodes are allocated to missile equipment; The RMFA is based on a meta-model which describes a schema of the model entities and their relationships between  Port: Associated with the Generic Missile SOI, Role- them (Fig.2). Each of these entities is described as follows: based Actors and Functional Nodes. Ports provide a ‘gateway’ into entities provided or required interfaces;  Commodity: A term used to describe data, information and physical entities, such as power. Commodities are passed across interfaces and processed by functions;  Interface: Contains events which allow interactions;  Event: Is the interface message;  Service: A collection of interfaces. Fig. 3. Launcher & Export Launcher role inheritance Fig. 4. Actor block showing interface ports Fig. 2. RFMA meta-model B. Missile Use Cases The RMFA use cases describe the RMFA goals and A. Role-based actors boundary of the generic missile. The goals span across the The RMFA model contains a set of around 30 functional full-lifecycle to include both operational (e.g. effect Target) role-based actors which can be used to create project-specific and non-operational (e.g. dispose System) use cases. The use actors for a missile project through the use of the object- cases have been developed as per industry standard, through oriented technique of inheritance. A functional role-based detailing the following for each use case: actor is responsible for a single functional atomic activity within the system, allowing for a flexible solution which can be  Use case goal: Elaborates the use case name and created quickly and be easily maintained. Projects that adopt describes the goal of the use case; the RMFA and use its functional role-based actors will be able  Primary actor: Describes the actor that initiates the to compare capability and functionality between them, interaction with the generic missile to a achieve a harnessing reuse where possible across the solution space. goal; A quick view of the Generalization relationship allows the  Pre-condition: The conditions that should be met interfaces described within the role based actors to reside on before the use case can commence; the launcher (Fig.3), it shows two variants of a launcher (actor, in blue), a standard “Launcher” and an “Export Launcher”. In  Trigger: The use case initiator; this instance the Export Launcher capability is a subset of the  Perceived functionality: Describes the superset of standard Launcher. The Export Launcher has the capability to functionality that the missile performs to answer the provide moment arm and alignment data through role-based use case goal. Alternative scenarios (“rainy day actors (in lilac). The standard Launcher inherits the Export scenarios”) are included at this stage. Launcher, thus it also can provide both alignment and moment arm data.  Success post-conditions: The condition the missile is To complete the example, Fig.4 shows how the Export in after the use case has finished successfully. Launcher inherits from the functional actors all the functional Note that for operational use cases, the perceived interfaces (the same applies for commodities). functionality is described based upon the high-level functionality defined within RMFA Functional Chains. C. Functional Chains RMFA has been developed through functional chains analysis, where a functional chain sequences together functions which form a well-defined sub capability. A set of 10 functional chains have been agreed across the international community. Each functional chain is composed of approximately ten functions, to capture the system functional behavior at both missile and equipment levels. During white box analysis, each function in the functional chains will usually be allocated to missile equipment (missile sub-systems). Such functional analysis aims to identify the functional & non-functional requirements attached to the functions and then will support the sub-systems requirements elicitation once the functions have been allocated to a specific sub-system. The system architect is encouraged to represent the link between functional chains and use cases (e.g. allocation matrix, Fig.5) and their relationship with time by associating functional chains to missile phases for each use case. These representations are very useful during complex systems development, allowing understanding of the system and its functionalities across multiple specialist teams. Fig. 6. Missile Architecture Landscape example The RMFA is layered and as per the project specific missile architecture landscape and contains both a context and Fig. 5. Example of association between functional chains and missile phases functional architecture (Fig.7). The context architecture for one use case contains a Reference Missile System of Interest which comprises of a superset of functionality and ports in which a subset of these would be referenced and used within a project- D. Missile phases specific architecture. The functional architecture contains a Missile operational lifecycle can be split in several time- super-set of functional nodes which could again be referenced related phases. A taxonomy of missile phases is proposed as and used within a project-specific missile architecture. The well as phase diagrams patterns. RMFA also contains a collection of functional interfaces and commodities which can be specialised and tuned according to VI. RMFA USE AND ‘TUNING’ TO SPECIFIC PROJECT the missile needs. A project-specific missile architecture model contains 3 layers, context, functional and physical architectures to represent the different types of analysis performed. (Fig.6 shows an excerpt). The context architecture describes the missile as a system of interest where external interfaces and high-level functionality is analyzed. This is often referred to as black-box analysis. The functional architecture layer decomposes the high-level system functions into smaller parts which can be allocated as a whole to the physical architecture. The physical architecture describes how the functions within the functional architecture can be allocated to missile equipment where a further allocation of non-functional requirements can be added. Fig. 7. RMFA Architecture Landscape RMFA acts like a missile architects toolkit where STAGE 3: The project completes the tuning by populating the functionality, commodities and services are referenced into the detail of any specialized commodity. In the example the project-specific architecture through the SysML concept of Project Specific Kinematic Criteria is populated with an inheritance (Fig.8, where project-specific missile context acceleration constraint (Fig.11). architecture is created from RMFA). Fig. 9. STAGE 1 – ‘Tuning’ RMFA Functionality Fig. 10. STAGE 2 – ‘Tuning’ RMFA Functionality Fig. 11. STAGE 3 – ‘Tuning’ GMFA Functionality If the required functionality is not available within RMFA, projects are able to create their own. The new functionality will be used to update RMFA and allow other projects in the MBDA portfolio to reference it. VII. CONCLUSIONS Fig. 8. Inheriting high-level missile functionality from RMFA The Reference Functional Architecture currently under development in MBDA, has proven to be a valuable asset and RMFA has been designed to be applicable across the has been implemented with success on a number of current MBDA portfolio solution space. The RMFA has been projects at various stages of the lifecycle. Its development has developed in conjunction with our current developments and been achieved through reverse engineering out current product considerations have been put in place to allow for scalable architectures and missile system design practitioners solution allowing for future products. contribution from across the business. The RMFA is a RMFA has been designed to allow functionality to be framework and guide for system architects, allowing them to reused directly by projects and to allow functionality to be reuse and tailor, through specialization of artefacts to create a tailored through the tuning of the function parameters. We can project-specific missile. The RMFA will provide an open, see the process of how functions, both at black and white box modular, robust, interoperable and cost-efficient reference for levels can be ‘tuned’ through specialisation and populated future developments while protecting classified and restricted accordingly to project needs: information through a layered approach. In addition, the RMFA has proved to be an excellent asset for knowledge STAGE 1: Describes the original function within RMFA. management. This example shows the Check Kinematic Criteria function which checks Kinematic Data against a Kinematic Criteria ACKNOWLEDGMENT giving a pass or fail result (Fig.9). This paper summarizes the outcomes that MBDA’s international team has produced, the authors would like to STAGE 2: The project references the function and thank the entire team. commodities from RMFA from its dedicated missile model. Dissemination of MBSE in MBDA Italy is made possible Any commodities that need to be ‘tuned’ are specialized using thank to Carlo Colandrea and Tonino Genito. a generalization relationship. The example shows the Kinematic Criteria has been specialized where a Project Specific Kinematic Criteria commodity has been created REFERENCES (Fig.10). [1] “Deploying MBSE into an International Company” – Andy Howells - [5] “Agile process for a Model Based System Engineering (MBSE) design” IBM Innovate 2012 - Christian Di Biagio and Pietro Piccirilli – 4th international Conference [2] “MBDA and our use of MBSE” – Ian Clark - INCOSE UK MBSE WG in Software Engineering for Defense Applications 2015 Meeting 2016 [6] “A Model-Based Safety and Dependability Methodology for Missile [3] “DoDAF Architecture Framework Version 2.02” - Safety Engineering” - Dieter Fasol, Burkhard Münker and Peter Bunus - https://dodcio.defense.gov/ 33rd International System Safety Conference 2015 [4] “MBDA Extendible Command & Control” - Christian Di Biagio, Pietro [7] “Computer interaction specification example” – Daniel Simmons, Piccirilli et al. - 4th international Conference in Software Engineering for Judith Astwood, Kerry Tatlock and Chris Vance – conference on Defense Applications 2015 Contemporary Ergonomics and Human Factors 2012 [8] “Methods & Tools for constrained system architecting” Jean-Luc Voirin – INCOSE International Symposium 2014