How to implement the IMOSA concept? What SE/AF should be considered for the OTF?

To undertake the IMOSA concept, it is required to select and adopt specific SE/AF. SE is an interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations and constraints into a solution and to support that solution throughout its life.⁴ To establish the way of working in SE several frameworks exist like NASA and EIA632 (freely available), ISO15288 and IEEE 1220 (both requiring subscriptions) and INCOSE (an extension of ISO 15288) which requires membership.

SE grows more necessary as the system becomes more complex. Take the example of development and integration of a swarm of heterogeneous UAVs equipped with different sets of payloads and providing ISR functions. Its design, development and operation involve such complexity that is not possible to manage without SE/AF. The first step is to create their architecture (or Enterprise Architecture) as a structured abstraction of reality and its detailed representation with the correct level of granularity in a way that is commonly agreed and unambiguous.

AF provides the guidance and rules for developing, representing and understanding comparable architectures based on common denominators and multinational boundaries. Several AF exist like Zachman, DoDAF, MODAF, TOGAF, IAF, FEAF, TEAF, SCOR, NAF, UAF.⁵ Those structured engineering approaches are requested, not only to clarify how things are designed, built and maintained, but as well to get a common description understandable by all the stakeholders and to ensure interoperability through a set of standards and specific methodologies.

The complexity and variety of standards can be displayed in the representation of Figure 2 from the European Defence Standards Reference System (EDSTAR) which is a repository of references to “best practice” standards and “standard-like” specifications.⁶

Current advances in Defence show a strong interest on making an overarching, compatible and interoperable Unified Architecture Framework (UAF) as a way to link with other AFs. The relationship to be made between DoDAF, MoDAF, NAF and UAF⁷ can be seen in Figure 3.

The wish from part of the Defence community would be to align the evolutions of MODAF v1.2.004 (U.K.) and MODEM v1.1 (MODAF Metamodel) into NAFv4.0 (NATO). That would be the basis of UAF v1.0 as an overarching framework which would be complemented from DoDAF 2.x (U.S. DoD) and DNDAF (Canada). This would be supported with the modelling language for Enterprise Architecture Archimate. 

ISO/IEC/IEEE42010⁸ provides means to define and specify AF in a uniform manner and develops a core ontology for the description of architectures. An architecture description language (ADL) is any form of expression for use in architecture descriptions. More recently, “wide-spectrum” ADLs have been developed which support a wider range of concerns like AADL, UML, BPMN, SysML or ArchiMate.

The Unified Modelling Language (UML) is a graphical language for visualizing, specifying, constructing and documenting the artifacts of a software-intensive system. It includes conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas and reusable software components.

There is a need to define and agree on an OTF to establish the common grounds for cooperation. The understanding and embracement of these concepts by all the involved communities is strongly required, at least from a high-level perspective. Stakeholders include those organizing and selecting research programs and projects together with the experts from Armed Forces and Procurement Organizations. This should normally be done through incremental approaches. The complexity of these methodologies is in contrast with their aim to ensure an unambiguous common understanding. The frameworks selected should be as simple and clear as possible only ensuring the coverage of the needs they are supposed to resolve. EDA projects related to these concepts are SMRF, SIMPLE, AMBASSADOR, RM4MRF, EORF, TACTICS, LAVOSAR I &II and STASS I & II.

An example of IMOSA—The EORF project: “Architectures for multifunction RF & Optronics sensors onboard RPAS platforms”

EORF9 was launched to explore the feasibility to define the IMOSA concept to achieve interoperability within payloads for small and medium RPAS (NATO class I and II). The BB defined, could be analysed and implemented in successive projects.

System advantages included the maximization of sensor data fusion performance, enhancing the RPAS capabilities in hostile environments and the improvement of the payload sensors interoperability and integration together with higher reliability, flexibility and lower product life-cycle costs for both manufacturers and final users.

Standards are essential to ensure adequacy of technical interface definitions, to allow comparisons and interoperability across vendors and systems and to create a shared competitive ecosystem. Examples of related standards are STANAG 4586 Unmanned Control System (UCS) UAV interoperability or STANAG 4626 covering modular and open avionics for architectures.

This would accommodate different payload configurations on the basis of combinations of sensors and weapons when needed; each one specifically designed in accordance with the intended results of the mission. Table 1 shows the list of the most common and currently available sensors for RPAS applications.

After the analysis of the existent frameworks and methodologies, TOGAF¹⁰ was selected as being an open framework specialized in Systems/Enterprise architectures being the best one fitting the requirements of the project. TOGAF needs to be complemented with another framework aimed at vertical business domains and horizontal technology or specific application areas. NAF was chosen for that purpose.

The EORF architecture is shown in Figure 4. The conceptualization of the BB is key in the definition of the target system architecture in order to make it modular and scalable. A certain combination of BB will be arranged for each mission/scenario. Consequently, “swapability,” understood as the possibility to use different kinds of sensors under the same interface, is needed. The BB have been divided into four different categories according to TOGAF: business, data, application and technology. As these four categories cannot be described in this article only the technology view is shown. Its aim is to define the interfaces and standards to be used at physical and logical level.

NAF NSV-2b (System to System Port connectivity) is shown in Figure 5. It describes the communication protocol and the physical port specification of each port on the system, having all BB in the IMOSA the same communication and power unit protocol. Two possible implementations have been proposed, one based on Ethernet and another based on RapidIO as shown in Table 2.

The Need to Promote and Use MBSE for Collaborative Programmes

MBSE is a SE paradigm that emphasizes the application of rigorous visual modelling principles and best practices to SE activities throughout the System Development Life Cycle (SDLC).¹¹ New Defence Systems require iterative processes for development in a way that incremental verification has to be applied during design. Given the cost and scale of investment to create a system, the life-cycle is becoming increasingly important affecting the operation and standards to create the product and the distribution of responsibilities amongst many defence contractors. The product acquisition life-cycle has to be tackled at all stages to properly cover all the needs of the stakeholders, so these methodologies have to be taken into account as of the pure research phase.  

The production process needs to include Through Life Cost (TLC) with all maintenance, disposal and training costs in addition to the cost of creating the product. MBSE as software-based data exchange methodology with extensive and traceable validation and verifications strategies is essential to ensure that the product fulfils the customer requirements. Apart of the entire design and development process, a modelling of the system should be used throughout the lifecycle considering simple models of the design parameters and how information is passed and maintained throughout the design and development stages.

This methodology facilitates both to provide feedback to the customer and to support the work of multiple partners upon the same material. AMBASSADOR,¹² a project of the European Defence Agency, predicted reductions in costs and time using MBSE by about a third and the decrease of associated risks in development cost and schedule by about two thirds which would suppose an impressive advantage.

Conclusions & Recommendations

Defence Capabilities and Technology Research in the EU require an overarching effort to structure and coordinate the several and different collaborative initiatives from a technical perspective to facilitate interoperability and ensure a successful outcome. From the author’s experience, a commonly agreed OTF including SE/AF and Simulation frameworks with common methodologies and tools would facilitate the cooperative work and improve interoperability. Among the methodologies to be used, MBSE is extremely powerful for cooperation and to de-risk the whole capability development process supporting verification and validation. Through the use of IMOSA and MBSE, research could be linked to capability development and very complex systems and systems of systems could be tackled, covering the TLC from a comprehensive perspective that could pave the way to future European Defence Capabilities.

References

1. https://eeas.europa.eu/sites/eeas/files/defence_fund_factsheet_0_0.pdf
2. “Special Issue ‘Surviving the Valley of Death’,” Elsevier, www.journals.elsevier.com/technovation/call-for-papers/special-issue-surviving-the-valley-of-death.
3. “Fact Sheet IP Management in Horizon 2020: Proposal Stage,” www.iprhelpdesk.eu/sites/default/files/newsdocuments/Fact-Sheet-IP-Management-H2020-Proposal-Stage.pdf.
4. ISO/IEC/IEEE 24765: 2010 Systems and Software Engineering—Vocabulary.
5. L. Urbaczewski and S. Mrdalj, “A Comparison of Enterprise Architecture Frameworks,” Eastern Michigan University, Vol. 7, No. 2, 2006.
6. “Expert Group 20: System Architecture,” EDSTAR, https://edstar.eda.europa.eu/DocumentLibrary/Download/51102dd0-d3b8-4663-8141-6b9b27242d22.
7. Gaetano D’Altrui, D.S01.3.1.1, “Study on Architectures Standards and Trends in the Defence Domain Inc.”
8. ISO/IEC/IEEE 42010:2011(E) Systems and Software Engineering—Architecture Description.
9. “16.ESI.OP.137 Architectures for multifunction RF and optronics sensors onboard RPAS platforms,” EORF.
10. The TOGAF Standard Version 9.2, www.opengroup.org/subjectareas/enterprise/togaf.
11. “What is MBSE?—What You Need to Know,” http://mbse.works/.
12. EDA Project AMBASSADOR—Advanced Model-Based Approach to Scalable Multi-Function Radio Frequency (SMRF) Specification, Analysis, Development and Obsolescence Reduction, May 13, 2013.