UNCLASSIFIED ANNEX A
Statement of Requirements – ISTAR Concepts and Solutions Engine Room
CONTENTS Page 1. Terminology 2 2. Background 2 3. The ICS Engine Room 4 4. The Engine Room Team Construct 6 5. The Engine Room Operation 10 6. Engine Room Management 13 7. Glossary 20 8. References 23
APPENDICIES Appendix 1 – Task-based Scenario for ICS Experiment Hub Appendix 2 – Task-based Scenario for Concept Development for [Redacted] Appendix 3 – Forward Experimentation Plan Appendix 4 – Core Competencies (Engine Room Leader and Strand Leaders) Appendix 5 – Engine Room deliverables Appendix 6 – Government Furnished entities (services, equipment, information, etc) Appendix 7 – The ICS Process
SUPPORTING INFORMATION [To assist in completion of task-based scenarios] Appendix 8 – ISTAR Experimental Hub – IOC Architectural Design Appendix 9 – Concept Capture PowerPoint presentation – [Redacted]
UNCLASSIFIED
1 UNCLASSIFIED ANNEX A
1. TERMINOLOGY 1.1 The term “Engine Room” covers all suppliers who shall form the Engine Room team, to be detailed by the Prime Contractor. 1.2 The term “The Contractor” shall refer to the Prime Contractor for the Engine Room. 1.3 The term “The Authority” shall refer to the Defence Science and Technology Laboratory (Dstl), an agency of the MOD.
2. BACKGROUND 2.1 The ISTAR Concepts and Solutions (ICS) Programme was initiated in July 2011 by the ISTAR and Sensors (I&S) Domain within the Defence Science and Technology (DST) Programme Office (PO), part of Dstl. ICS will enable Science and Technology (S&T) to take a whole-systems approach in addressing MOD Unified Customer (MUC) problems and issues across the ISTAR enterprise. 2.2 “Concepts”1 within the scope of ICS (specifically Applied Concepts) are focused primarily on ISTAR Capability Requirements which are defined as ‘services to decision-makers’ within the ISR2 Enterprise Architecture (EA). The Authority will provide access to MOD Reference Architectures (such as the Information Superiority Reference Architecture) during the life of the programme. These concepts may be combinations of equipment, processes, tactics, techniques, training & procedures that may comprise varying sets of ‘capability components’ (or ‘capability building blocks’) that are intended to meet a desired requirement or level of capability. Herein where the term concept is used the above description is assumed. 2.3 In addressing ISTAR problems and issues, ICS will inevitably impact on other areas, from dismounted combat to littoral manoeuvre, and as such ICS will be required to be coherent with ongoing work and future plans across a broad range of capability areas which will be dependent on the specific concept under investigation. 2.4 The I&S Domain receives ISTAR S&T research goals (RGs) from the capability areas within MOD, and these span the complete ISTAR enterprise from integrated sensing and collection, to intelligence analysis and production. In order to address the RGs, MOD S&T needs to: • Understand the intelligence enterprise • Have knowledge of where it does and does not work • Understand the contribution S&T can make to the enterprise • Have vision, leadership and motivation.
2.5 The scope of the ICS programme will include the whole of the I&S Domain S&T programme, which is sub-divided into eight application areas. These are: • [Redacted}
2.6 Each of the eight application areas draws from some or all of the six Domain research areas, which are:
1 DCDC defines a concept as ‘a notion or statement of an idea, expressing how something might be done or accomplished, that may lead to an accepted procedure or capability.’ Concepts can be further sub-divided into Analytical and Applied Concepts. ‘Analytical Concepts assist with the formulation of Defence strategy by describing in broad terms, the principles and characteristics of future ways of operating out to a 20 year horizon ‘(e.g. High Level Operational Concepts). ‘Applied Concepts describe specific ways of operating within existing policy and provide the detail required to support capability development and delivery via the Through- Life Capability Management (TLCM) process. The most detailed examples of Applied Concepts are CONEMPs and CONUSEs.’ 2 Intelligence, Surveillance and Reconnaissance UNCLASSIFIED
2 UNCLASSIFIED ANNEX A
• Concepts and Capability: focus areas for decision support to capability planning and acquisition3 • Sensor Technologies: multi-function sensor systems built from a common core of technologies reusable across land, sea, air and space • Sensor Exploitation: extraction of the maximum possible information from sensor data at its lowest level of digitisation • Integrated Sensing: synchronised, cross-cued sensing across sensor modalities, platforms and environments to provide guaranteed detection, recognition, identification and tracking of targets • Information Exploitation: optimised extraction and interpretation of information from all available data sources • Intelligence Production: detection, association and correlation of events across the widest range of disparate sources
2.7 Each application area may cut across one or more operational environments (Land, Sea, Air, Space, Cyber and Spectrum), or part of the “Direct, Collect, Process, Disseminate” (DCPD) Intelligence cycle4, and impact on one or many Defence Lines of Development (DLoD)5, [Redacted] Figure 1: ICS interaction with the eight I&S Domain application areas.
2.8 Each Application Area has a dynamic S&T roadmap, access to which shall be provided to the Contractor by the Authority from Contract start date6, which cover: • Exploitation plans • Demonstrations • Underpinning technical activities, including those both in-Government and from the supply base, including S&T research and development of: o Concepts, architecture and enterprise o Networked systems o Systems and sub-systems o Science and technology research 2.9 [Redacted] 2.10 The ICS programme aims to address these issues and will develop and validate new (and existing) concepts for future ISTAR solutions to: • Address MUC Research Goals and future capability gaps, risks and issues which will be maintained and interpreted by the Authority • Provide understanding of cost, benefit and timescales/risks to the MUC • Exploit innovative technology and systems approaches across the DCPD cycle, to inform the design of the ISTAR Enterprise 2.11 The chosen delivery method for Industrial and Academic support to the ICS programme is via the Engine Room contract. The Authority believes that MOD and a technically excellent Engine Room, led by a Prime Contractor, working together in a collaborative environment, is the
3 The ICS Programme is a core element of this research area 4 Joint Doctrine Publication 2-00 [1]; Understanding and Intelligence Support to Joint Operations. 5 DLoD descriptions [2]; Acquisition Operating Framework 6 A list shall be maintained in Appendix 6 of all items to be provided as GFX (e.g. information, services, equipment, etc) UNCLASSIFIED
3 UNCLASSIFIED ANNEX A
construct most likely to succeed in delivering this complex, fast paced, technically challenging programme. 2.12 The ICS Programme shall take a rigorous approach to test and evaluation of concepts, which will ensure that only those high-priority concepts that: • Address a MOD-endorsed problem • Have a viable exploitation route • Deliver real benefit to the end-user will be developed into a solution. The work of the Engine Room will be key to delivering this approach. There will be scope for innovative exploratory activities where, for example, future technology options generated by the Centre for Defence Enterprise (CDE) will be examined within a complete DCPD test environment. 2.13 The Engine Room will form the core of the ICS Programme. Concept ideas, captured by the Authority, will form the basis of Engine Room tasks to take each concept through an iterative process of development and assessment, resulting ultimately in the production of detailed E2E solution options – i.e. proposed solutions to the original customer problem (against which the concept was generated). Invariably not all concepts will reach this stage of maturity, as the ICS process shall be structured such that concept development can be put “on-hold” or terminated at any stage, if: • MOD priorities change • Assessment activities show it will not deliver a solution which meets the customer requirement, • A particular technology is not at a sufficient level of maturity to take the Concept further. 2.14 Assessment activities, such as cost analysis, benefits analysis, or E2E system assessment will therefore underpin concept development. Concepts will be tested through combinations of simulation, modelling and both emulated and live experimentation (which may include full-scale live experiments) across the complete system-of-systems architecture.
3. THE ICS ENGINE ROOM OVERVIEW 3.1 The following are the overarching requirements of this Contract for the provision of the ICS Engine Room. 3.2 Day-to-day management of the Engine Room at a task level shall be the responsibility of the Contractor, with leadership and technical oversight from the Authority. There shall be close cooperation between Dstl and Engine Room staff in the delivery of individual tasks under this contract. 3.3 The Engine Room shall be flexible, dynamic and built on a culture of sharing and collaboration to achieve a common goal. It will have an “open-door” policy to ensure that suppliers can join and leave depending on programme priorities. Elements of the Engine Room shall be embedded at Dstl Porton Down where suitable infrastructure for the embedded Engine Room staff shall be provided by the Authority. 3.4 “Embedded” refers to staff whose permanent place of work for a period of time greater than 2 months is at Dstl Porton Down. Embedded staff shall be required to hold appropriate security clearances (minimum SC) and be UK Nationals. 3.5 The Authority shall ensure embedded staff undergo site induction; be issued with a pass; and have provision made for IT equipment. 3.6 The Authority will make four single occupancy open-plan office spaces available for the use of the embedded Engine Room at Dstl Porton Down, for the duration of the programme. The Contractor shall provide details of how it shall make use of this provision, and which staff will be UNCLASSIFIED
4 UNCLASSIFIED ANNEX A
embedded at Dstl Porton Down at different stages in the Programme. Regular reach-back to other, non-embedded, members of the Engine Room shall be required to be detailed by the Contractor. 3.7 There shall be a requirement for a surge of Engine Room staff to be co-located with the Authority during some activities, for example during large-scale live experiments. Requirements for IT, desk, and office provision shall be assessed by the Authority on a case-by-case basis. 3.8 The Engine Room shall be supported by a broad range of sub-contractors, managed by the Prime Contractor, which shall draw on subject matter expertise from large, medium and small UK based companies and academia to provide a broad capability in support of the ICS programme on a rolling basis. 3.9 Throughout the life of the ICS programme suppliers shall be able to join or leave as required, managed by the Contractor, and dependent on the evolving priorities of the overall programme. This is of particular relevance when looking to exploit extant ‘best of breed’ technologies into ICS architectures. As stated in the recent UK Government White Paper “National Security through Technology” 7, “it is critical that large companies make best use of their supply chains, including Small and Medium-sized Enterprises (SMEs) and academia, and in particular follow an open systems design approach, to ensure that best technology in each domain is offered to Government. It is also important that industry and academia collaborate to facilitate this.” And; “We need to be able to use effective investment in defence and security science & technology to access and deliver technology into our future systems and equipment to provide operational advantage.”
3.10 The Government has identified SMEs as a key focus6 to deliver innovation and support growth, with an aspiration that 25% by value of Government contracts should benefit small businesses in the future. In order to align the ICS programme with this aspiration, the Contractor: • Will maximise the cost-effective use of SMEs in the delivery of work through the ICS Engine Room • Shall identify an initial Engine Room membership with capabilities to provide the required services • Will have access to a wide supplier base with which they have a good working relationship • Shall be adequately resourced to deliver a coherent programme of multiple tasks including the placement of, potentially, multiple sub-contracts in a timely manner. 3.11 The Authority shall be part of the decision-making process in conjunction with the Contractor in the placing of tasks on specific suppliers, and shall retain the right to veto or mandate specific supply. This is to ensure that the Authority is able to take action to protect Sovereignty of UK Capability as required.6 3.12 The Contractor shall be required to integrate extant research from the MOD research programme into ICS at the discretion of the Authority, working collaboratively with extant research suppliers either from within Government (including Foreign Governments) or in Industry, in the delivery of Engine room activities. Specific items will be provided to the Engine Room as Government Furnished entities (GFX, including equipment, information, etc), and the Contractor shall be responsible for maintaining a list of GFX provided by the Authority, and the security assurance issues for access and management by the various suppliers/sub-contractors for each element of GFX. 3.13 The Authority shall be responsible for ensuring that appropriate Non-Disclosure Agreements
7 National Security Through Technology: Technology, Equipment, and Support for UK Defence and Security [3] UNCLASSIFIED
5 UNCLASSIFIED ANNEX A
(NDAs) are in place in order to service the requirement of Section 3.12. 3.14 The initial membership of the ICS Engine Room shall be proposed based on current concept priorities (Section 5.1) and experimental plans (Appendix 3 – Long term Experimental Plan). 3.15 The Engine Room shall contain three core strands of work. The process underpinning each strand is provided in Appendix 7. Tasks within each strand shall be split between the Authority and the Contractor. The Contractor shall also undertake supporting activities such as building of the ICS Experimental Hub (ref. Task #1). These strands comprise: Concept Development: This is an 8-stage process, which will start from production of an initial prioritised concepts list, decomposing the problem that the concept is trying to address to allow identification of the potential improvements. It will conclude with development of technical designs for E2E solution options which will be assessed by the Concept Assessment strand. Concept Assessment This strand provides a coherent assessment service to inform the selection, prioritisation, development and validation of novel and extant concepts, capturing and evaluating the benefits of outputs and mapping these benefits, and to develop and demonstrate an evolving but enduring framework (within Dstl and Industry) to model and cost E2E ISTAR concepts at appropriate levels of system abstraction, and to provide costed recommendations to the MOD Customer. Live and Simulated Experimentation This strand provides a suitable framework to enable concepts to undergo rigorous testing in a complex environment, considering the impact on the full DCPD ISTAR cycle (or cycles). Exploratory test environments will allow lower Technology Readiness Level (TRL) concepts and technology options to be tested, for example from Centre for Defence Enterprise (CDE) projects. Table-Top Exercises (TTX) will also be conducted, drawing on MOD Subject Matter Expertise in order test hypotheses in a validated environment. The credibility of the test methodologies must be upheld through engagement with the Military user by means of Working Groups. Supporting activities The Contractor shall supply and maintain a specific hardware and software solution to enable experimentation activities (see task 1 for FOC Hub, for which the Authority must have full rights of ownership and usage, including after the expiration of the Contract. 3.16 Through the Engine Room multiple Tasks will be let against the Terms and Conditions of this contract. Each Task will have its own Statement of Requirements (SOR) against which the Contractor shall cost and describe the work to be undertaken. The Contractor shall work with the Authority, and provide technical assistance as appropriate, to fully define the Statement of Requirement for each Task to develop their formal proposal and quotation. The costs for this support shall be included as part of the ad-hoc support required from the Contractor, as detailed in Section 4.8. 3.17 Eight concept development tasks, and building of the ICS Experimental Hub, will start sequentially after the contract commencement date. Concept titles are given in Section 5.1, and the Contractor shall be responsible for producing Concept development plans in order to service this requirement.
4. THE ENGINE ROOM TEAM CONSTRUCT 4.1 The ICS Programme Leadership Team will be made up of, as a minimum: • DSTL: Technical Leader, Project Manager, and Strand Leaders
UNCLASSIFIED
6 UNCLASSIFIED ANNEX A
• Contractor: Engine Room Leader, Programme Manager, Strand Leaders and sub-contractor representatives, where appropriate. 4.2 The Authority believes that there are no core Engine Room roles that have an essential requirement to be embedded full time at Dstl Porton Down, and the contractor shall propose a model to ensure that the embedded Engine Room staff remains flexible to the needs of the programme. 4.3 The Contractor shall be responsible for reviewing all output from the Engine Room, to assure quality of output. For deliverables outside Dstl to the MOD Customer (or other parties, e.g. International collaboration), independent technical review of programme deliverables will be performed by a review team as specified by the Authority in accordance with the Dstl Governance process which shall be supplied by the Authority from Contract start date. 4.4 The diagram in Figure 2 shows the proposed lead responsibilities across the programme. Roles within the Authority are marked in grey; those within the Engine Room are marked in white.
ICS ICS Dstl Project Manager Technical Leader Core Team
Programme Engine Room Manager Leader ICS Technology Concepts Lead
Assessment ICS Assessment Lead Lead
ICS Experimentation Experimentation Lead Lead
Systems ICS Systems Concepts Lead Concepts Lead
ICS ENGINE ROOM
Figure 2 – ICS Organisation. Roles owned by The Authority are shown in grey, those owned by the Contractor shown in white.
4.5 The Engine Room shall be under the overall leadership of the Authority. The Authority will provide a Technical Leader and Project Manager who will together be held accountable for the success of the overall programme. The Authority shall be responsible for: • The overall strategic direction of ICS; • MOD Stakeholder engagement; • Monitoring of the Engine Room contract and associated sub-contracts as detailed in Section 7. • Technical quality of deliverables to the MOD Customer from the overall ICS programme. Should deliverables from the Contractor not be of a sufficient standard or meet the agreed requirement, they will be rejected and must be resubmitted or a reduction in the cost of the deliverable agreed. UNCLASSIFIED
7 UNCLASSIFIED ANNEX A
4.6 The Authority will provide Dstl Strand Leaders for each of the core strands of work within ICS, providing strategic direction and responsibility for engaging with the MOD Stakeholder Community, as well as overall control and accountability for all work undertaken within each Strand (whether done in Government or within the Engine Room). 4.7 There must be a close working relationship with the Authority at both the Programme and the Technical level, to involve regular meetings and other communication on a frequent basis, to ensure coherence between the in-Government work performed within ICS, and that undertaken by the ICS Engine Room. 4.8 To ensure close working, the Contractor shall ensure that there is capacity within the Engine Room team to respond to ad-hoc tasking from the Authority. It is envisaged that this could amount to approximately 25% loading. 4.9 All staff involved in the performance of the Contract must have appropriate security clearances (UK nationals with minimum of SC) to support ICS Engine Room activities. 4.10 In addition the Contractor must be willing to security clear additional staff as required or increase the clearance level of selected staff to DV if required.
4.11 ICS Engine Room Leader 4.11.1. It is a requirement that the ICS Engine Room lead is a direct employee of the Contractor. The appointment of a single lead for all Engine Room activity is critical to the success of ICS. The person taking on this role must have a demonstrable track record in the delivery of complex programmes of work. 4.11.2. The ICS Engine Room leader shall be responsible for: • Day to day technical work of the Engine Room to ensure coherence between the Strands. • Developing requirements for future tasks in collaboration with the Engine Room members and Contracting Authority. • Setting strategic programme direction in collaboration with the Dstl ICS Technical Lead. • Ensuring that procurement of technologies and services is undertaken via fair and open competition unless otherwise directed by the Authority. • Delivery of all Engine Room activity 4.11.3. The ICS Engine Room leader shall demonstrate the competencies detailed in Appendix 4 (Core Competencies). 4.11.4. The ICS Engine Room leader shall be available in a full-time capacity from contract start date. 4.11.5. The ICS Engine Room leader shall be available for the duration of the programme unless Condition 29 (Contractor’s Personnel) of the Conditions of Contract applies.
4.12 ICS Engine Room Programme Manager 4.12.1 The Contractor shall appoint a programme manager to support the Engine Room Leader. 4.12.2 The ICS Programme Manager shall be responsible for: • Delivering Tasks to time, cost and quality. • Ensuring adequate resources are available to undertake the work of the Engine Room within tight deadlines, from the Contractor, partnering companies, and sub-contractors. • Developing and implementing the Engine Room governance framework • Managing the Engine Room budget, monitoring expenditure and costs against UNCLASSIFIED
8 UNCLASSIFIED ANNEX A
benefits as the programme progresses • Managing the performance of the programme team • Maximising the efficient allocation of resources and skills • Managing communications between internal stakeholders (i.e. internal to the overall ICS Programme) 4.12.3 The ICS Programme Manager shall demonstrate the core competencies shown in Appendix 4.
4.13 ICS Engine Room Strand Leaders 4.13.1 The Engine Room Strand Leaders will mirror the Dstl Strand Leaders, and will be responsible for providing technical oversight and coherent delivery of outputs to all tasks under their remit (as detailed in Section 5). They will work in close collaboration with each other and the associated Dstl Strand Leads. 4.13.2 The Contractor shall provide appropriately qualified personnel as Strand Leaders for each of the three Engine Room Strands within the programme: • Concept Development • Assessment • Experimentation They shall be under the management of the ICS Engine Room leader, but will also report on a regular basis to the Strand Leaders employed by the Authority. 4.13.3 Personnel for all three ICS Engine Room Strand posts may be drawn from a mix of staff from the Prime Contractor and the wider Engine Room team, as appropriate. 4.13.4 The ICS Engine Room Strand Leaders must demonstrate the competencies detailed in Appendix 4 (Core Competencies), excluding those marked as applicable only to the ICS Engine Room Leader. 4.13.5 The ICS Engine Room Strand leaders shall be available for the duration of the programme unless Condition 29 (Contractor’s Personnel) of the Conditions of Contract applies. 4.14 Other key skills 4.14.1 There are a number of key skills that shall be required in order to deliver the range of activity within ICS, and these must be provided by the Engine Room. The Contractor may also suggest other skills not within this list which it believes will add benefit: • Process Architecting • ISTAR and Sensor Systems technical architecting • Systems Engineering & Analysis • ISTAR systems integration • ISTAR and Sensor Systems modelling & simulation • Benefits analysis • Pan-DLOD analysis • Costing and Cost Analysis • Operational Analysis • Information and data management • ICT development and maintenance (inc. Experimental Hub) Synthetic Environment expertise • Experimental design UNCLASSIFIED
9 UNCLASSIFIED ANNEX A
• Field Trials and Experiment execution • Human Factors assessment • Operational ISTAR expertise o Technical o Military
5. ICS ENGINE ROOM OPERATION 5.1. Introduction 5.1.1. The processes underpinning each strand have been developed by the Authority during the pilot year of the ICS programme, and an overview of this process is included in Appendix 7. The Contractor shall adopt these processes at the outset of the contract, and shall develop and optimise these throughout the life of the programme 5.1.2. At Programme start-up, 50 unique concepts were identified by the Authority that vary in Application area, context, granularity and priority. Ten have been identified as high priority, which shall be tasked to the Engine Room following Contract award, to be developed from initial Concepts through to, potentially, full E2E Solutions (depending on the outcome of Assessment activities, which may halt Concept development at the discretion of the Authority any point during development). These Concepts are: • [Redacted]
5.2 The Systems Concepts and Assessment Process 5.2.1 Concept Development and Assessment 5.2.1.1 The Authority will be responsible for generating the Concept list and for generating Concept Capture OV-1s for high priority concepts, leading to Decision Gate (DG) 1. 5.2.1.2 The Authority shall have responsibility for all activity leading up to DG-2. The Contractor shall support this stage as required (including in development of the Statement of Requirement for future concept development), which shall be dependent on the skills and expertise that the Contractor can supply to the Engine Room. Specific activities at this stage which the Contractor shall supply include: • Analysis of Technology options to determine the “as-is”, and the future technology shortfalls against the Concept Options, including looking at whether MOTS & COTS systems exist that may provide a satisfactory solution to the concept without the need to develop new capability. • Providing comparative, qualitative, assessment services within Assessment Level 2 including benefits, dis-benefits and impacts across the various DLoDs. 5.2.1.3 Other areas where the Contractor may make an input shall be agreed between the Authority and the Contractor following contract award. 5.2.1.4 The Authority envisages that formal tasking on the Engine Room for development of E2E Solution Options and associated Level 3 Assessment activity will occur at DG-2. 5.2.1.5 Each concept development and assessment task placed on the Engine Room will contain the key components that have been developed in the pre-DG2 stages of concept development and assessment. This output will include: Concept Capture Decomposed Problem Concept Options report, including:
UNCLASSIFIED
10 UNCLASSIFIED ANNEX A
o Benefits analysis o Technology Analysis o DLoD impacts 5.2.1.6 A handover from the Authority to the Contractor shall be required in transitioning from developing Concept Options/Assessment Level 2, to developing E2E Solution Options/Assessment Level 3. This may take the form of a meeting, workshop, or other series of activities to be defined by the Contractor. 5.2.1.7 It is envisaged that it shall take 2-3 months to complete all pre-DG2 activity, and generate the post-DG2 tasking on the Engine Room
5.2.2 End-to-End Solutions and Assessment Level 3 - Tasking on the Engine Room 5.2.2.1 This stage shall be initiated by formal tasking from the Authority on the Engine. All activity under this stage (excluding the production of final recommendations at DG-4) shall be undertaken by the Engine Room unless stated in specific tasking documentation, and be managed as individual projects controlled by the Engine Room Leader and Engine Room Programme Manager with oversight provided by the Dstl Technical Leader and Project Manager. 5.2.2.2 There shall be close working between the Dstl and Contractor Strand Leaders throughout the development of each Concept following formal tasking on the Engine Room. The Authority shall maintain overall control of each Concept under development, and the terms and conditions of each task shall be such that the Authority may halt Concept development or redirect work, should MOD Customer priorities or other Programme drivers change. 5.2.2.3 The central element of each task will be for the Contractor to mature Concept Options which have passed through DG-2 and develop them into full E2E Solutions underpinned by Assessment Level 3. 5.2.2.4 The Contractor will be required to develop a Concept of Analysis (COA) to pass DG-3. 5.2.2.5 It is assumed that the E2E system assessments will predominantly draw upon and integrate sub-system or component modelling (e.g. sensor modelling) undertaken elsewhere (within Government and/or Industry). 5.2.2.6 The Authority recognises that in some cases such models may either not exist or be available to the Authority. In such cases targeted sub-system or component modelling (e.g. sensor modelling) activities will be undertaken as appropriate. More generally, MOD would benefit from not just procuring the sensor equipment in isolation, but together with the models that characterise and quantify how well and under what conditions these sensors perform. To enable this, any sub-system or component modelling conducted by the Contractor shall be compatible with the Integrated Test & Evaluation Framework (ITEF) developed by the Authority for other models of ISTAR capability. The Authority will provide guidance on this framework from contract start date. 5.2.2.7 It is critical that the sub-system or component modellers, Subject Matter Experts, capability level modellers and cost analysts are brought together rather than working within separate communities. The ICS assessment work strand shall require a rapid and flexible integration of virtual teams shaped by the nature of the concept to be assessed. 5.2.2.8 The Contractor shall provide evidence to support a relative balance of investment activity if multiple solution options reach DG-4 (and are amenable to comparative analysis). 5.2.2.9 For single solutions or solution options that cannot be compared relative to each other, the Contractor will undertake a cost effectiveness analysis.
UNCLASSIFIED
11 UNCLASSIFIED ANNEX A
5.2.3 Demonstration to Stakeholders 5.2.3.1 The Contractor shall conduct a demonstration of E2E solutions, in order to demonstrate that the benefits that were identified in the Concept Capture stage are achievable (Figure 6). 5.2.3.2 This demonstration must be cognisant of the outputs of the Concept Capture stage and the demonstration must ensure that the stakeholders involved in the concept are satisfied that the E2E solution has the ability to meet their needs. 5.2.3.3 This shall be an element of live Experimentation activities (Section 5.3).
5.2.4 Costed Interventions and Recommendations 5.2.4.1 The Contractor shall produce a set of costed interventions and recommendations to meet the requirement of DG-4, which will decide which solution options: • Are to be developed to a level where a COEIA8 can be produced for scrutiny prior to business case submission to the Investment Approvals Committee (IAC); • Require further technology development within the I&S Domain; • Require further demonstration and validation; • Are to be placed on hold or rejected.
5.3 ICS Experimentation 5.3.1 An experiment could be required at various points as a concept matures and similarly may support analysis at several Assessment Levels, and therefore cannot be assigned to any particular stage of Concept development and Assessment. The decision to undertake an experimental activity will be the responsibility of the Authority, driven by need to: a) De-risk the integration of technology or systems; b) Demonstrate or showcase the concept to stakeholders; c) Provide data on measurements of merit to validate or refine the assessment; d) Discover issues not assessed or problems that have not been foreseen.
5.3.2 The Contractor shall undertake ‘set piece’ themed experiments that will likely perform a range of coordinated experimental activities driven by all four of these drivers. Of these only c) and d) would directly inform the assessment process. 5.3.3 The Authority has provided an experimentation plan (Appendix 3) which shows priorities out to 2016. This will be under regular revision by the Authority, in response to external variables such as the Defence Equipment and & Support (DE&S) equipment programme and Planning Round outcomes, Defence R&D Board priorities, MOD area of operations, and technology development. 5.3.4 The Authority will task the Engine Room with Experimental activity. This may be part of a concept development tasking, or form a separate tasking in its own right (as experiments may encompass multiple concepts). 5.3.5 The experimental service provided by the Contractor must be flexible to adapt to the changing requirements and include: • Experimental leadership • Updates to the long term ICS experimental plan (Appendix 3). • Delivery and maintenance of a FOC Experimental Hub to satisfy planned live DCPD experimentation (Appendix 1). Planning and execution of experimentation across all of the DLoDs
8 COEIA: Combined Operational Effectiveness and Investment Appraisal UNCLASSIFIED
12 UNCLASSIFIED ANNEX A
• Planning and execution of experiments involving human participants, to include experimental design, ethics considerations, measurements, analysis and interpretation of results. • Experimentation across a range of TRLs and SRLs • Synthetic Experimental capability • Combined live and synthetic experimentation • Integration and conduct of a coherent series of live field trials, live laboratory trials, simulation & emulation. • Production of scenarios, vignettes and supporting material that is consistent with MOD Studies Assumptions Group (SAG) scenarios and has been endorsed by Dstl Military Advisors to provide suitable experimental stimulation • Training of experimental actors in the use of tools, applications and processes supporting the experiment • Collaborative experimentation working closely with the supply base, MOD Unified Customer, Front line Users and Dstl • Supporting research development experimentation across the research programme through exploitation of the ICS core capabilities and core capabilities within this area.
5.3.5.1 Within a given year, the Contractor must be able to deliver a range of experimental activities, including but not limited to: • One major set piece live DCPD experiment per year (combination of live field trial and synthetic environments, simulation, data collection, user in the loop) of the order of 4 weeks duration. • Two minor live DCPD experiments per year (field or lab based) of the order of 2 weeks duration each. • Over the year period, 6 weeks of lab-based technical experiments (modelling, simulation, facilitating the testing of research capability)
5.3.5.2 The Authority will provide access to facilities for undertaking experimentation, the scope of which shall be determined on a task-by-task basis and be dependant on availability. The Contractor may also propose its own facilities, or that of a member of the Engine Room, to be used during experimentation. Facilities that will be provided by the Authority include: • Dstl Porton Down range facility (outdoor locations and labs) • Dstl Porton Down SANDBOX facility (simulating the information environment on current operations) • Joint Multi-National Interoperability Assurance Network (JMNIAN) • Ranges accessible under the Long-Term Partnering Agreement • Other MOD owned facilities • Other sites accessible under International agreements. 5.3.5.3 For experiments undertaken overseas, the Contractor shall be responsible for export documentation, logistics, and for ensuring its staff hold the appropriate clearances for the country in question. 5.3.5.4 All data collected during experimental activities under this contract shall be owned by the Authority.
6. ENGINE ROOM MANAGEMENT 6.1 Management of the Contract 6.1.1 Overview UNCLASSIFIED
13 UNCLASSIFIED ANNEX A
6.1.1.1 The ICS Engine Room shall be managed in accordance with standard management best practice, and the Contractor shall describe the Project/Programme Management system to be employed. The following Section describes the Authority’s expectation for programme Governance. 6.1.2 Progress Meetings, Presentations and Reports 6.1.2.1 Meetings 6.1.2.1.1 There are two types of meeting required, plus a Start-up Meeting: 1. Monthly Management Meeting 2. Annual Review The details of which are described below.
6.1.2.2 Start Up Meeting: 6.1.2.2.1 A contract start up meeting shall be required, the date of which shall be informed by the Authority upon Award of Contract.
6.1.2.3 Monthly Management Meetings 6.1.2.3.1 Monthly Management meetings shall be held to update progress on the supplier engagement and technical maturity of the tasks under the contract. This will enable the Authority to obtain confidence in the programme delivery and ensure sufficient supplier engagement. 6.1.2.3.2 These are to be held at a mutually convenient date and location, to be agreed. The meetings will be chaired by the Contractor.
6.1.2.4 I&S Domain Quarterly Supplier Reviews 6.1.2.4.1 The Contractor may be asked to prepare and give presentations on the research being undertaken at I&S Domain Quarterly reviews. Presentations incorporating comments from the Authority shall be prepared a minimum of 5 working days in advance of the presentation.
6.1.2.5 ICS Programme Annual Review and Report 6.1.2.5.1 The Contractor shall hold an Annual review for the ICS Programme at 12, 24 and 36 months to the Dstl ICS Project Manager, chaired by the Authority. The review shall be attended by the Project Manager, Technical Leader, and other relevant MOD or Dstl Stakeholders invited by the Authority. The reviews must evaluate the outputs, outcomes and benefits of programme itself. The Contractor shall provide a mechanism for the programme to be re-directed if it is failing to make sufficient progress against its objectives. 6.1.2.5.2 The Contractor shall produce a Programme Annual Report at 12, 24 and 36 months from the start date of the contract. The report shall be delivered to the Dstl ICS Project Manager within 2 weeks of the due date. The report shall summarise programme benefits, technical progress and give a balanced account of both high and low points to record the lessons from the programme as a whole. It shall be written in such a way as to convey both technical achievement and the relevance to MOD’s capability planning and delivery requirements. The report shall reference any external publications, milestone reports or internal technical working papers produced during the year. The written report shall be supplemented by a presentation to the Dstl ICS Project Manager at the related Annual Review meeting.
UNCLASSIFIED
14 UNCLASSIFIED ANNEX A
6.1.2.6 Presentations and Summary Reports 6.1.2.6.1 Where the milestone is a Presentation or Demonstration rather than a Report, the Contractor shall prepare and issue a draft Milestone Summary Report to MOD and Dstl staff attending the milestone presentation/demonstration at least 10 working days before the date of the presentation/demonstration. A final Milestone Summary Report incorporating comments from the Authority, as per the Dstl Governance process, shall be produced within 10 working days of the milestone presentation/demonstration. 6.1.2.6.2 The Contractor shall propose deliverables that mark significant points during the course of each task. The achievement of these deliverables shall be demonstrated to the Dstl Project Manager and Technical Leader by means of a Report, and/or a Presentation, and/or a Demonstration. Presentations/demonstrations will be attended by the Project Manager, Technical Leader, and other relevant MOD or Dstl Stakeholders invited by the Authority. 6.1.2.6.3 Milestone Summary Reports must be aimed at potential users and stakeholders and must therefore be written in a clear and concise style. Diagrams and pictures may be included where they would assist explanation. The report should include the following sections:
• Executive Summary • Defence and Technical Context – including relevance to MOD’s capability planning and delivery requirements; also the relationship of this deliverable to those milestones that have been delivered in the past and those to be delivered in the future. • Aims of the Task – expressed as desired outcomes that make clear the Defence relevance; • Scientific & Technical Progress – a clear, succinct and brief explanation of what has been achieved (including areas were the research did not achieve the objective) avoiding jargon and making use of diagrams, graphs and illustrations as appropriate; • Defence Capability Implications of Task – including militarily significant highlights; • References & Publications – any technical articles/papers and other publications produced to date.
6.1.2.7 Final Summary Paper 6.1.2.7.1 The Contractor shall produce a short Paper at the end of the Contract, targeted at non-technical stakeholders, summarising the overall achievements of the Contract.
6.1.2.8 Final Technical Report 6.1.2.8.1 The Contractor shall produce a Final Technical Report at the end of the Contract summarising the research undertaken and detailing the achievements of the Contract and its relevance to MOD’s capability planning and delivery requirements. 6.1.2.8.2 The Final Technical Report must be aimed at potential users and stakeholders. The aim of the report is not to record the detailed technical and scientific achievements of the project but rather to explain what has been achieved and its significance in a Defence context. It is important to detail aspects of the research that did not produce the desired outcome, as these may constitute an important contribution to the knowledge base.
UNCLASSIFIED
15 UNCLASSIFIED ANNEX A
6.1.2.8.3 The Final Technical Report shall contain the following sections: • Executive Summary • Defence and Technical Context - including relevance to MOD’s capability planning and delivery requirements; • Aims of the Project - what were the original desired outcomes of the project, expressed in a way that makes the Defence relevance clear; • Benefits achieved and those yet to be realised • Scientific & Technical Progress – a clear, succinct and brief explanation of the research undertaken and what was achieved (including areas were the research did not achieve the desired outcome) avoiding jargon and making use of diagrams, graphs and illustrations as appropriate; • Defence Capability implications of Project – including militarily significant highlights; • Recommendations - how is pull-through/exploitation to be achieved, identifying candidate specific exploitation injection points where possible, who should / will take action and when. • References & Publications - List of all the technical articles/papers and other publications produced during the course of the project; • Point(s) of Contact for Further Information.
6.1.2.9 Format of Reports 6.1.2.9.1 All Technical Reports shall be prepared in accordance with DRRS (Defence Research Reports Specification) latest issue, which can be provided by the Authority.
IT Standards 6.1.2.10 In addition to hard copies of all deliverables and reports, an electronic copy shall also be supplied. The soft copies shall be in Microsoft Office 2007 format or a version to be agreed from time to time. The Contractor shall ensure and certify that all magnetic media supplied to the Authority under this Contract has satisfied the Contractor’s virus checking procedure and is free of all viruses known to the Contractor.
6.1.3 Security 6.1.3.1 All security matters must be dealt with in accordance with the Security Aspects Letter (to be issued on contract award) and MOD JSP 440. Specific Security Operating Procedures may be issued for some activities; Engine Room staff will be expected to comply with these. 6.1.3.2 For any Engine Room activity hosted on the Contractor’s site, properly MOD accredited IT facilities for the processing and storage of Restricted, Secret must be available. 6.1.3.3 Where possible, all documentation supplied under the Contract shall be written in such a way as to minimise the required Security Classification. This may be achieved with two separately bound documents, the main document having the lower classification with a more highly classified annex.
6.1.4 Research Integration 6.1.4.1 It is absolutely vital that research conducted by the contractor is made widely available to the MOD and its Stakeholder Community. The Contractor will therefore be expected to provide a minimum of one hard copy of all reports to the Project Manager, and distribute soft copies to an agreed list of other parties.
UNCLASSIFIED
16 UNCLASSIFIED ANNEX A
6.1.5 Distribution 6.1.5.1 The Contractor shall be responsible for distributing copies of minutes and reports. The distribution list shall be agreed at the Contract Start Up Meeting and will include the following:- i. Dstl Technical Leader ii. Dstl Knowledge Services Information Centre, Building 247, Dstl Porton Down, Salisbury, Wilts SP4 0JQ iii. Electronic copies of formal deliverables to Dstl Project Manager and nominated Dstl technical staff. iv. Dstl Commercial Department
6.1.6 Publication in the Open Literature 6.1.6.1 Where practical publication and presentation in the open scientific/defence related literature and at symposia/conferences is expected and encouraged. Requests for publication must be made through the Authority, in consultation with the Project Manager. In all publications (except the Journal of Defence Science) authors must acknowledge the Research Programme as follows:
“This work was carried out as part of the ISTAR and Sensors Domain Research Programme.”
6.1.7 Ad hoc Meetings, Briefings or Presentations 6.1.7.1 One of the roles of the DST Programme Office is to provide guidance on science and technology policy to senior MOD staff and Ministers. The Contractor may occasionally be required to provide information to enable MOD to prepare briefing material, or to answer specific technical questions, possibly at short notice. On rare occasions the Contractor may also be asked to prepare and give presentations on the research being undertaken to senior MOD or OGD officials. The Contractor should expect no more than 2 significant requests per annum.
6.1.8 Publicity Material 6.1.8.1 The Contractor may also be asked to provide publicity material in the form of photographs and/or written material, for use in MOD publication
6.1.9 Annual suppliers conference 6.1.9.1 The Contractor shall provide an annual suppliers conference at 12, 24 and 36 months from contract award. This will provide an opportunity for suppliers involved in the ICS programme, including suppliers not part of the Engine Room (such as CDE suppliers) to share progress to date, and also demonstrate developments to key stakeholders.
6.1.10 Contract Programme Plans 6.1.10.1 A detailed contract programme plan, covering all authorised Projects and Tasks, shall be maintained throughout the life of the contract. The plan is to be available to the Engine Room at all times.
6.1.11 Resource Management Plan UNCLASSIFIED
17 UNCLASSIFIED ANNEX A
6.1.11.1 Ensuring that relevant manpower and other resources are available to undertake planned activities is the responsibility of the Engine Room Programme Manager. It is acknowledged that not all Engine Room staff will be required full-time at all times. 6.1.11.2 A detailed resource management plan, covering all authorised Tasks, must be maintained. The plan should address: • Engine Room staff deployment • Estimated effort and cost 6.1.11.3 All staff, irrespective of employer, must be available when required; however, for staff who are not working full-time on the ICS programme a notice period of, at least, 5 working days will be given by the Authority. 6.1.11.4 Any issues with the provision of staff for the ICS programme should be addressed to the Dstl Project Manager.
6.1.12 Information Management 6.1.12.1 All data and information provided to or generated by the Engine Room must be maintained and stored in such a way as to comply with MOD security, data protection and IPR protection requirements. 6.1.12.2 All contract project management documentation must be available, electronically, to the Authority at all times. 6.1.12.3 An online repository has been developed by the Authority during the pilot year of ICS – the “ICS Portfolio”. This is hosted by the Authority, and is available on the MOD Intranet. The Contractor shall provide resource to manage the storage and sharing of data through the ICS Portfolio. 6.1.12.4 For embedded Engine Room staff, shared server folders will be provided by the Authority for day-to-day working.
6.1.13 Contract Management 6.1.13.1 During the life of the contract a number of sub-contracts will be required to be let by the Contractor. A detailed sub-contracting plan must be maintained for the duration of the contract. 6.1.13.2 It is expected that contracting action will be required within all of the Tasks let under this contract. 6.1.13.3 The Contractor will be expected to undertake: • Preparation of Statements of Requirements. • Vendor selection and appraisal. • Value-for-money reviews with the Authority and commercial branch • Placement of sub-contracts. • Sub-contract management. • Management of sub-contract risk. • Management of sub-contract IPR. • Appraisal of sub-contract outputs. • Payment of sub-contract.
6.1.14 Risk Register 6.1.14.1 The Authority requires that a Risk Register be maintained for the contract project, UNCLASSIFIED
18 UNCLASSIFIED ANNEX A
covering all authorised Tasks. The register must detail the risks, risk owners, risk score, controls, mitigations and contingencies.
6.1.15 Task Definition 6.1.15.1 Provision shall be made to assist the Authority in the preparation of Statement of Requirements for Tasks that have not yet been defined.
6.1.16 Safety, Health, Environment & Fire (SHEF) compliance 6.1.16.1 SHEF Risk Assessments or Safe Working Practice documents must be supplied to the Authority for authorisation prior to the commencement of any activity not connected to routine office or travel activities. An example of both shall be supplied with the response to this Statement of Requirements. 6.1.16.2 Specialist SHEF Advisors will be available to assist with the preparation of complex SHEF risk assessments if required. 6.1.16.3 If the Engine Room is hosted on a MOD site, all staff will be expected to comply with all extant SHEF requirements of that site.
UNCLASSIFIED
19 UNCLASSIFIED ANNEX A
7. GLOSSARY
ARL Army Research Laboratories CDE Centre for Defence Enterprise CESMO Collaborative Electronic Support Measures for Operations COA Concept of Analysis COEIA Combined Operational Effectiveness and Investment Appraisal COTS Commercial-off-the-Shelf DCPD Direct, Collect, Process, Disseminate DE&S Defence Equipment and Support DG Decision Gate DJtCap Directorate (Joint Capability) DLoD Defence Line of Development DP Dimensional Parameters DST Defence Science and Technology DV Developed Vetting EA Enterprise Architecture EPSRC Engineering and Physical Sciences Research Council ES Electronic Surveillance EW Electronic Warfare FCAS Future Combat Air System FIST Future Integrate Soldier Technology FOC Full Operating Capability GCHQ Government Communications HQ
GFX Government Furnished entities (inc. Equipment, Information, Services, etc) IAC Investment Appraisals Committee ICS ISTAR Concepts and Solutions IM Information Management IMS Integrated Management System IOC Initial Operating Capability IP Intellectual Property IPR Intellectual Property Rights IRC International Research Collaboration ISR Intelligence, Surveillance and Reconnaissance
20 UNCLASSIFIED ANNEX A
ISTAR Intelligence, Surveillance, Target Acquisition and Reconnaissance ITA International Technology Alliance ITEF ISTAR Test and Evaluation Framework ITT Invitation to Tender JDN Joint Doctrine Note JSP Joint Service Publication MOD Ministry of Defence MODAF MOD Architectural Framework MOFE Measurements of Force Effectiveness MOIE Measurements of ISTAR Effectiveness MOM Measurements of Merit MOP Measurements of Performance MOTS Modified off-the-shelf MUC MOD Unified Customer NIS Network and Information Sciences OA Operational Analysis PB Programme Board RG Research Goal SA Situational Awareness SAG Studies and Assumptions Group SC Security Cleared SDSR Strategic Defence and Security Review SE Systems Engineering SHEF Safety, Health, Environment, Fire SIE Single Intelligence Environment SIGINT Signals Intelligence SME Small and Medium-sized Enterprise SOR Statement of Requirement Redacted] StV Strategic View TRL Technology Readiness Level TTX Table-Top Exercise UAV Unmanned Air Vehicle UCAS Unmanned Combat Air System UDRC University and Defence Research Consortium UNCLASSIFIED
21 UNCLASSIFIED ANNEX A
VKB Virtual Knowledge Base
UNCLASSIFIED
22 UNCLASSIFIED ANNEX A
8. REFERENCES [1] Joint Doctrine Publication 2-00; Understanding and Intelligence Support to Joint Operations; http://www.mod.uk/DefenceInternet/MicroSite/DCDC/OurPublications/JDWP/Jdp200UnderstandingAndIntelli genceSupportToJointOperations.htm
[2] DLoD descriptions; Acquisition Operating Framework; http://www.aof.mod.uk
[3] National Security Through Technology: Technology, Equipment, and Support for UK Defence and Security; http://www.mod.uk/DefenceInternet/AboutDefence/CorporatePublications/PolicyStrategyandPlanning/Natio nalSecurityThroughTechnologyCm8278.htm
UNCLASSIFIED
23 UNCLASSIFIED ANNEX A
[INVITATION TO TENDER – EVALUATION TASKS: APPENDICIES 1 & 2]
[Tenders are to note the tasks in Appendices 1 and 2 shall be used in the bid evaluation model]
[In the evaluation of Tenders, bidders shall provide detailed plans against each task including costs and a breakdown of work required, answering any specific questions within each task.]
APPENDIX 1: Task 1 - ISTAR experimental hub Full Operating Capability (FOC)
A1.1 Task 1 - ISTAR experimental hub Full Operating Capability (FOC) A1.1.1 The Contractor shall provide a proposed FOC Hub design which covers the capabilities described in this Appendix. A1.1.2 The Authority has provision at Dstl Porton Down, to provide networked laboratory space that can be utilised to host the FOC Hub. A1.1.3 The Authority has a key long term requirement to enable live and simulated experimentation encompassing any or all aspects of the ISTAR Direct, Collect, Process and Disseminate (DCPD) intelligence cycle. The requirements of the experiment hub reflect that the experimental capability has to: • Be able to exercise the whole DCPD cycle; • Be able to represent all relevant organisations; • Provide suitable Integrated Management Systems (IMS); • Be able to accommodate live sensor feeds. • Be able to integrate synthetic representation of the enemy and sensors • Be reactive to short-term needs A1.1.4 An experimental hub Initial Operating Capability (IOC) (herein referred to as the IOC Hub), based at Dstl Porton Down, has been developed against a set of initial experimental requirements derived from the need to explore efficiencies in dynamic ISTAR asset re-tasking. This has included the provision of specific hardware and software which is detailed in the IOC Hub architectural design (included in Appendix 8 as GFX). The IOC Hub will be provided as GFX as detailed in Appendix 6. A1.1.5 An Enduring Capability to run experiments is required from the Full-Operating Capability Experimental Hub (hence referred to as FOC Hub). A high level view of the required layers within the FOC Hub is shown in Figure 3. This comprises, amongst other things: • Applications • Data • Infrastructure components • Communications. • Open standards and supports security at multiple levels of classification.
UNCLASSIFIED
24 UNCLASSIFIED ANNEX A
Figure 3 - Outline Design
A1.1.6 Experiments will apply the enduring capability and enhance it with specific experimental environments that may be synthetic or live. These environments may exist for a single experiment, or may persist across multiple experiments. They could be independent of the enduring capability or be amalgamated into it for future re-use. The preferred approach is to exploit existing capability through a federated approach. The amount of federation is likely to vary depending on the experimental hypotheses and opportunities for collaboration. A1.1.7 A management layer is required across all environments to address the day-to-day running of experiments and the ability to swap between experiment configurations. This is focussed purely on the ICS business / experimentation space and is therefore not an element that is likely to be federated. A1.1.8 Figure 4 shows an architectural overview of the FOC Hub, capturing components established by the IOC and concepts that are key to delivering FOC. This Appendix explores the constituent parts of the FOC Hub, including an enduring capability supported by a mixture of core and deployed hubs. A1.1.9 This enduring capability will be configured according to the needs of each experiment and augmented with specific systems as appropriate. A1.1.10 The execution of the experiments increases the collateral within the FOC Hub and hence increases its capability (see Appendix 1). A1.1.11 The experiment execution environment needs to be representative of the live, operational environment, which will vary depending on the Concept under test.
25 UNCLASSIFIED ANNEX A
Figure 4 - SV-1 ICS System Overview
A1.1.12 Enduring Capability A1.1.12.1 The enduring capability must cover all aspects of the solution that can be applied to the planning, execution, analysis and management of current and future experiments. It will increase over time as the experimental collateral builds. A1.1.12.2 The following list covers areas which shall be addressed in the enduring capability, but is not exhaustive: • Application Hosting • Data storage • Experiment data capture and playback • User directory and management • Office Applications • User Collaboration (e.g, IRC/chat, VoIP, email etc) • Knowledge Management • Configuration Management • Backup / Restore • Patch & Release Management • Support for experiment execution • Data record / playback (e.g. video) • Sensor integration (e.g. CESMO) • Geographic display of platform and sensor data • Capable of integration with other systems (at differing security levels) (other systems are any ISTAR capability across the DCPD cycle, e.g. sensors, processing, etc)
UNCLASSIFIED
26 UNCLASSIFIED ANNEX A
• Capable of federation with other Experimentation systems A1.1.13 The enduring capability includes Experimentation Collateral: those elements that can be used within future experiments. Every experiment instantiation will increase the experimentation collateral, as a minimum adding to the captured data. The collateral will comprise, though is not limited to; • Experiment execution processes and procedures • Scenarios • Vignettes • Vignette supporting scripts & information • Reference data • Captured data • Interfaces to other systems • Applications • Tools • Simulators • User accounts and roles • Equipment • User Guides / Training Material • Configuration / Release Baselines • Integration and experimental experience (lessons learned) • Networking and Collaboration A1.1.14 The Contractor shall outline how it will build on the existing IOC hub designs to achieve the FOC capability. The IOC Hub shall be provided by the Authority as GFX, however the FOC Hub is not required to include any of the IOC Hub components. However any alternatives must be cost effective A1.1.15 The FOC Hub design must detail the proposed level of capability achievable based on available extant systems, tools and processes. This shall include:
• Provision of a central infrastructure (to include but not limited to cables and wireless communications and IT equipment), including a portable set of equipment that could be run either in a laboratory or in the field e.g. within an ISO container) and adequately protected (To include physical security, firewalls and network assurance), re-configurable to support live distributed and networked trials (including multifunctional operationally representative work stations) and able to operate (if required) within a multilayer classification environment; • Ensuring the central infrastructure is suitably mobile. It is envisaged that the majority of Experimental activity will be based at Dstl Porton Down, Salisbury. However, some experiments may be at alternate locations, thus the Contractor must ensure the central infrastructure is sufficiently mobile that it may be moved as required • The building, integration and maintenance of networked computing within the common experimental hub architecture (workstations, machines, servers, clients, communications, data logging devices etc) and connectivity to external information sources (including representative ISTAR sensors, networks and datasets.) Desirable attributes of the integration capability include;
o Reusable
UNCLASSIFIED
27 UNCLASSIFIED ANNEX A
o Agile o Flexible o Configurable o Federated o Service Oriented o Standards Compatibility • Provision of a wide band communications bearer network which can be configured / constrained to represent likely operational communications bearers for particular concepts under test (note that a Tactical data network is provided as GFX, described in Appendix 6). • The provision of an overarching information management system utilising interfaces with open standards and protocols (preferably Internet Protocols- based) to enable:
o Collaborative working within and between MOD, Industry and allies for Experimental activity;
o Ability to add enhanced DCPD functionality (e.g. new sensor types and additional users);
o Provision of data logging, storage, caching, and retrieval capabilities;
o Communications between six or more remote ISTAR sensors (e.g. control, display and manual/automatic cueing and cross- cueing). • A description of any additional facilities and GFX that Dstl will need to provide during the build and testing of the FOC hub and for running the live experiment. • Live and simulated experimentation in support of the live data collection (including an emulation and simulation capability). • A full documentation set to reflect how the experimental hub is set-up, including a detailed component level interface control document and soft copy of source code for non-background items. A1.1.16 The Contractor shall outline how it proposes to meet the expected capability, timescale and stages for completion of the experimental hub. A cost breakdown must be provided including: • Hardware costs • Manpower costs (setup and operation of the Hub) • Licensing/software costs
Serial Milestone Date due 1 Contractor to receive full FOC experimental hub specification from Contract Start Authority, and develop implementation plan Date
2 Build of experimental hub completed + 4 months 3 ISTAR experimental hub test phase + 4 months 4 Delivery of fully operational hub, including a detailed component level + 5 months interface control document
UNCLASSIFIED
28 UNCLASSIFIED ANNEX A
5 First DCPD experiment at which the experimental hub will be deployed Feb 2013
APPENDIX 2: Task 2: Concept Development for [Redacted]
A2.1 Task 2: Concept Development for [Redacted] A2.1.1 Overview A2.1.1.1 The Contractor shall provide a costed plan detailing how it will take the Concept from Concept Capture, through to E2E Solution Options with the appropriate level of assessment at each stage.. Further detail on all stages of concept development and assessment is included within the supporting information and in Appendix 7. A2.1.1.2 The plan shall be in accordance with (but may suggest enhancements to) the Concept development and assessment processes. A2.1.1.3 It will form the basis of the Statement of Requirement for one of the first tasks to be placed on the Engine Room from Contract award. A2.1.1.4 The high level overview of this concept is shown in Table 1. A2.1.1.5 Supporting information has been provided, specifically: • Appendix 9: Concept Capture MODAF views – PowerPoint presentation
Table 1 – Concept description for [Redacted] [Redacted] Task Objectives A2.1.1.6 The objective of this Task is to develop and assess E2E solution options that can be validated in order to present the MOD Customer with a set of recommendations. A2.1.1.7 The Contractor shall detail the approach that will be used in developing and assessing the concept, including: • Information that would be required from the Authority • Capabilities that would be employed • Review points • Description of Assessment Level 3 Concept of Analysis (ref. Appendix 7) A2.1.2 Timescales A2.1.2.1 A plan shall be set out as to how and what the Contractor shall deliver against this Task.
UNCLASSIFIED
29 UNCLASSIFIED ANNEX A
APPENDIX 3: Proposed ICS Experimental Programme
[Redacted]
UNCLASSIFIED
30 UNCLASSIFIED ANNEX A
APPENDIX 4: Core Competencies (Engine Room Leader, Programme Manager and Strand Leaders)
Technical Leadership (excluding Programme Manager)
Regardless of whether I have Line Management responsibility for people, I demonstrate leadership in my specialist field of expertise and use this to build capability and create value for the programme.
Focus Strategically – Engine Room Leader only
I think long term and see issues beyond the confines of my role. I look to bring ideas to life by working across Functions and Departments. I take personal responsibility for moving the programme towards its vision.
Personal Responsibility
I take ownership for issues and prioritise effectively to meet commitments and desired outcomes. I organise myself to deliver effectively, efficiently, safely and securely. I take responsibility for what I say and do and I am prepared to challenge others who compromise standards.
Working Effectively Together
I collaborate effectively with a range of different people, sharing knowledge and building positive, trusting relationships. I engage with others who may have a useful contribution to make and who may be interested in the outcome of my work. I influence others appropriately to affect the outcome of situations.
Managing my Impact
I am aware of the impact I have on others and how they view me. I modify the way I communicate, as necessary, to ensure that I can relate effectively to and influence individuals inside and outside of the team.
Communicate Effectively
I communicate in clear, concise and appropriate terms. I am able to create understanding across a wide range of technical and non-technical audiences both verbally and in writing. I listen actively in order to build shared understanding.
Apply Innovation UNCLASSIFIED
31 UNCLASSIFIED ANNEX A
I think laterally and creatively in order to introduce new approaches and solutions. I have a continuous improvement mindset and apply my knowledge to take the programme forward.
Drive for Results
I drive for shared results and implemented processes. I manage performance effectively by sharing what I expect of people while also helping them set and achieve stretching deliverables and outcomes. I recognise successes and address poor performance. I show resilience in overcoming complications and setbacks.
Effective Networks and Joint Working
I actively establish and maintain dialogue with a range of internal and external contacts, networking effectively to expand the accessible pool of knowledge, resources and expertise to help the programme deliver its objectives. I create effective joint-working arrangements, and where appropriate, help to establish important contractual agreements that enable constructive debate and add real value.
Understanding the Defence and Security Environment – Engine Room Leader only
I am aware of MOD’s programmes and capabilities, and the relevance of this programme to all of the stakeholders and suppliers. I am in touch with developments that may influence the programme now and in the future. I understand how the programme differs from that usually undertaken by MOD.
UNCLASSIFIED
32 UNCLASSIFIED ANNEX A
APPENDIX 5: ICS Initial Deliverable List
[This list will be subject to change following contract award, and individual Task deliverables shall be added to this list]
Serial Title Details Due date
1.1 Engine Room Team – create The Contractor shall form the core Engine 2 weeks from Room team, ensuring staff have the Contract award appropriate security clearances
1.2 Engine Room Team – embed The Engine Room team will be set up at 4 weeks from its core locations for reach-back and Contract award embedded support
1.3 Engine Room Team – resource The Contractor shall provide a resource 4 weeks from plan plan for the first year of the Contract, contract award describing the resources to deliver the outputs of the ICS programme
1.4 Annual Suppliers Conference Section 6.1 1 year from Contract award
1.5 Contract programme plan Section 6.1 Maintained throughout contract life
1.6 Risk register Section 6.1 Maintained throughout contract life
T1.1 ICS Experimental Hub Deliverable Build of experimental hub completed 31 Sept 2012 #1 (hardware and software)
T1.2 ICS Experimental Hub Deliverable Delivery of fully operational hub, including 31 Oct 2012 #2 a detailed component level interface control document T1.3 ICS Experimental Hub Deliverable First DCPD experiment at which the Feb 2013 #3 experimental hub will be deployed
UNCLASSIFIED
33 UNCLASSIFIED ANNEX A
APPENDIX 6: List of Government Furnished Information, Equipment, Services and other entities.
This is not an exhaustive list and shall be maintained by the Contractor as the programme progresses.
Item Description
Site and To include: infrastructure for embedded Engine - Office furniture Room team - IT equipment (laptop with MS Office software, docking station, keyboard, mouse, etc). Note that other specific software may be made available on request through the Authority, but must be certified by the Dstl Compliance team for use on Dstl Networks.
- Amenities (kitchen area, toilets, parking)
- Site pass (inc. car pass)
ICS Core Team The Authority will provide a core team to lead the ICS Programme. This will consist of: Technical Leader, Project Manager, 4 strand leaders.
Experimentation A draft Experimentation plan, out to 2016, is provided as an Appendix to the Plan Engine Room contract.
SAG Scenario set Scenarios from which Experimental vignettes shall be developed by the Contractor shall be provided when required.
IOC Hub The IOC Hub, including equipment, software that has extant licences and documentation, will be provided by the Authority.
Application Area S&T Roadmaps for the ISTAR and Sensors Domain application areas will be Roadmaps provided
ISTAR Test and The Authority shall provide access to, and guidance on, this framework Evaluation Framework
Experimentation A number of experimentation facilities will be provided, including (but not limited facilities to)
- Dstl Porton Down outdoor range
- Dstl Porton Down networked laboratory facilities
- SANDBOX test-bed, Porton Down
- JMIAN
- Ranges covered by the LTPA
- Other facilities provided by International partners
UNCLASSIFIED
34 UNCLASSIFIED ANNEX A
shall provide the Governance process to the Contractor from contract start date. All deliverables from ICS to its MOD Customer shall be reviewed using this process.
UNCLASSIFIED ANNEX A
APPENDIX 7 – The ICS Process
9. The ICS Process 9.1 Overview 9.1.1 A process has been developed during the pilot first year of ICS operation shown in Figure 5. Each element of this process is described in this Appendix. This Appendix does not cover which elements of the process are the responsibility of the Authority or the Contractor, detailed in Section 5.
Figure 5 – ICS Process Flowchart. Dark grey indicates activity predominantly undertaken by Dstl, light blue shows activity predominantly undertaken by the Engine Room. Partial shading shows areas of handover.
9.1.2 Generated concepts will be at a range of granularities and apply to different application areas and timeframes, and as such will be developed and assessed in an iterative/spiral manner. The more mature concepts will be tested and evaluated through experimentation (with the results fed back into concept development and assessment). 9.1.3 Experimentation is a central tenet of ICS and there will be a rolling programme of live and simulated DCPD Experimentation across all years of the Programme to support Concept Development. 9.1.4 Concept Development can also be described by a systems engineering process shown in Figure 6, where the E2E solution options validate the problem decomposition and the demonstration to stakeholders validates the concept capture. Validation may include live experimentation, table-top exercise (TTX), synthetic environment, workshop, or other mechanism which the Engine Room will provide. 9.1.5 Assessment activities will run in parallel to, and underpin, ongoing concept development and drive experimentation as shown in Figure 7. The purpose of the ICS assessment
UNCLASSIFIED
36 UNCLASSIFIED ANNEX A
strand is: • To provide a coherent assessment service to inform the selection, prioritisation, development and validation of novel and extant concepts • To capture and evaluate the benefit of outputs from ISTAR solutions to priority concepts and to map these benefits to ISR Military Services (i.e. the goals, benefits and requirements of ISTAR, such as “support to force protection measures”). • To develop and demonstrate an evolving but enduring framework (within Dstl and Industry) to model and cost End to End (E2E) ISTAR concepts at appropriate levels of system abstraction.
Figure 6: ICS Concepts Plan – Systems engineering process
9.1.6 All Assessment activities shall be: • Federated and coherent. Approaches shall seek to exploit and develop extant tools, capabilities and current/planned programmes where appropriate. Dstl and Industry Operational Analysis (OA) and sub-system or component modelling approaches shall have coherent inputs and outputs. To enable this, any sub-system or component modelling conducted shall be compatible with the Integrated Test & Evaluation Framework (ITEF) developed by Dstl for other models of ISTAR capability. • Thorough. Performance and cost assessments shall encompass the relevant capability components within the E2E ISTAR DCPD cycle (or cycles) across the appropriate Defence Lines of Development (DLoDs); • Validated. An audit trail shall be generated that may inform future business case development with assessment outputs and supporting evidence deposited in the ICS Portfolio. 9.1.7 The following terminology shall apply to concept development: • Assessment Levels define the degree to which the concept has been analysed or validated (e.g. benefits identified, E2E system modelling or through experimentation or demonstration); • Decision Gates are points within the development or assessment of a concept where a UNCLASSIFIED
37 UNCLASSIFIED ANNEX A
decision is made (e.g. to reject, hold or embark upon further development and/or assessment).
Figure 7 – Assessment Strand structure
9.2 Concept Identification 9.2.1 Initial Concept Identification 9.2.1.1 ICS is driven by the MOD Capability Research Goals (RGs). The RGs define the scope of the ISTAR issues being addressed by ICS (in which research has a role in understanding and resolving). 9.2.1.2 ICS will generate concepts against these issues using a range of sources including: • Capability Audit • High Level Operational Analysis • Capability & Programme Investigations • Operational Lessons Learnt • Capability Planning Group/Programme Board plans (& risks) • DCDC Analytical Concepts & Strategic Trends • Technology Watch & Horizon Scanning
9.2.1.3 Stakeholder engagement will be key to capturing these issues, and understanding the problem. ICS will draw on a number of resources including: • Dstl Capability Advisors; • Technical Subject Matter Experts; • Military Advisors; and, where available and appropriate members of the MUC and Stakeholder community. 9.2.1.4 Generated concepts will be at a range of granularities and apply to different application areas and timeframes, and as such will be developed and assessed in an iterative/spiral manner. The more mature concepts will be tested and evaluated through experimentation (with the results fed back into concept development and assessment). 9.2.1.5 Concept maturity and associated evidence (of, for example, benefit and cost) will be used UNCLASSIFIED
38 UNCLASSIFIED ANNEX A
on making both within the MOD research programme and wider TLCM decision making (particularly in Stages 4 and 5, but also Stages 2-6). 9.2.2 Concept List Management 9.2.2.1 Concept list management maintains the list of all concepts, manages their importance to the ICS project, and communicates the concepts with the stakeholder community. The Engine Room will be responsible for maintaining the list of all concepts within the ICS Portfolio. 9.2.2.2 All high priority concepts as listed in Section 5.2.1 will be developed at least to the concept capture stage. Whether these concepts are taken to further stages of assessment will depend on subsequent assessments, and development on a particular concept may be stopped by the Authority at any time.
9.3 Concept Capture 9.3.1 Key questions to be addressed at this stage regarding each concept are: • What are the benefits? • What is the problem that this concept helps solves? • What would the solution look like? 9.3.2 MODAF compliant views will be produced, including: • The StV-1 ‘Vision’: describes the Vision, High level Benefits and Functions of the Concept. • The OV1a “As-Is” Concept Graphic: The problem space the Concept addresses is explored and confirmed with stakeholders via this view which highlights the problem/ Capability Gap via a rich picture. • The OV-1a “To-Be” Concept Graphic: Describes the Concept benefits in the form of a rich picture and to provide a possible To-Be instantiation. • The OV-5 “Use-case model”: enables both procedural driven functions and discrete event functions to be modelled and analysed in a similar format. 9.3.3 Examples of Concept Capture for [Redacted] are included as supporting information to this contract. 9.3.4 At the completion of the Concept Capture, Assessment Decision Gate 1 will decide when the new concept should be matured further under the Problem Decomposition Stage.
9.4 Problem Decomposition 9.4.1 The aim of this stage of the concept development is to decompose the problem in order to allow identification of the potential improvements, in specific areas, offered by the new concept. Key questions to be addressed are: • What does the concept improve? • What are metrics for measuring improvement? • By what degree will the concept offer an improvement? • How are improvements measured? 9.4.2 Stakeholder engagement and military advice at this stage is critical in order to understand who perceives the current capability to address a problem as an issue. 9.4.3 The output of Problem Decomposition should be summarised with statements defining exactly what the System Under Study (SUS) is, along with a re-phrased Problem Statement ensuring that ICS understand the problem being addressed by the concept. 9.4.4 Outputs from the problem decomposition will include: • solution elements captured • statement of the outputs that users require from the system, containing information that UNCLASSIFIED ANNEX A
relates to the overall capability need • record of the background and operational context 9.4.5 This statement of outputs could be used to inform a future User Requirements Document (URD).
9.5 Developing Concept Options 9.5.1 The systems concept strand will evolve the solution elements identified during the Problem Decomposition Stage and aggregate them appropriately (based upon DLOD impacts, system and technical feasibility) to form concept options. 9.5.2 Targets associated with the metrics identified in the Problem Decomposition Stage and more detailed requirements shall be developed, through access to MOD Reference Architectures (such as the Information Superiority Reference Architecture). 9.5.3 Technology analysis will also be performed at this stage, including looking at whether MOTS & COTS systems exist that may provide a satisfactory solution to the concept exists without the need to develop new capability; 9.5.4 The appropriate stakeholder will then develop a system (equipment or procedure) of the concept for assessment at the next stage, along with a Concept of Employment (CONEMP). 9.5.5 At the completion of Developing Concept Options, Decision Gate 2 will decide whether the new concept should be matured further to the next stage of development.
9.6 Assessment Level 2 9.6.1 As indicated in Figure 7, Assessment Level 2 runs in parallel to both the Problem Decomposition and Developing Concept Option stages of concept development. 9.6.2 Activities at this level shall produce a comparative qualitative assessment (benefits, dis- benefits, impacts across the various DLoDs and likely/ potential technology shortfalls) of the solution elements and Concept Options developed during Problem Decomposition and Developing Concept Options. 9.6.3 Comparisons shall be made between ‘competing’ solution elements and concept options and the ‘as is’ or baseline system or process. The relationship between this level of assessment and concept development shall be spiral, in that outputs from the assessment should influence concept development. 9.6.4 It is envisaged that this level could be undertaken in 2-3 months (dependent on the nature and number of solution elements / concept options generated). 9.6.5 Here it is critical to ensure that fair comparisons can be made. It may be the case that after Concept Capture / Assessment Level 1, several discrete concepts can be identified as providing benefits to the same capability, capability component or ISR Military Service. In which case, if their capability boundaries are consistent, these concepts can be grouped together for assessment purposes. 9.6.6 This Assessment Level will begin with the generation of a concept of analysis for comparative benefits analysis (Benefits COA). This will ensure that the problem is sufficiently well understood, concept options are compared fairly, appropriate Figures of Merits (FOMs) are used and extant models are exploited or developed. At this stage an appropriate Studies and Assumptions Group (SAG) scenario(s) should be chosen and endorsed (based upon Subject Matter Expertise and appropriate Military Judgement e.g. from a concept specific User Working Group (UWG)). 9.6.7 Benefits Analysis will begin with Problem Formulation where a better understanding of the specific questions for assessment and the nature of validation will be developed together with will be an initial estimate of the likely scope of the assessment (including analysis
UNCLASSIFIED
40 UNCLASSIFIED ANNEX A
objectives, timescales, assumptions, constraints and resources). NATO COBP for C2 Assessment provides guidance how this should be undertaken. 9.6.8 Benefits Identification shall identify benefits9, dis-benefits and beneficiaries (e.g. stakeholders) and provide of a subjective assessment of the likely impacts on the relevant DLoDs based upon Subject Matter Expertise and appropriate Military Judgement (e.g. from a concept specific UWG). Benefits should be linked to the appropriate ISR Service within the ISR Services Taxonomy. This activity will also output an initial indication of which capability components are yet to be validated or where specific technology innovation is required. 9.6.9 Benefits mapping shall produce casual maps10 for the each concept option and the ‘as is’ or baseline approach. The benefits maps shall illustrate the full set of benefits and sub- benefits, how these relate to each other, and they link to elements within the ISR Services Taxonomy. This exercise will help ensure that concept capability boundaries are consistent. 9.6.10 At this point the Benefits COA may call for Benefits Modelling to be undertaken to compare the benefits of the competing solution elements / concept options. In which case, a benefits model will be produced where a scoring or weighting mechanism has been applied to the causal maps produced by the Benefits Mapping activity to generate a numerical output in the form of a FOM. Such scoring and weighting should be appropriately validated by Subject Matter Experts and appropriate Military Judgement (e.g. from a concept specific UWG). 9.6.11 Another output from this level of assessment will be a qualitative assessment of the relative impacts across the relevant DLoDs for the concept options under test. This information can then be used to inform Decision Gate 2 in order to reject those concept options that would likely require unacceptable levels of investments within one or more of the DLoDs. 9.6.12 At this stage is may be possible to identify concept options that are candidates for potential experimentation at a later point (either to de-risk the integration of technology or systems or to demonstrate or showcase the concept to stakeholders). Together with the ICS Experimental Strand, the assessment at this level should seek to generate questions which can then be developed into experimental hypotheses (based upon the potential benefits that a concept option may deliver). Note that specific experimental MOMs would not be generated at this point. 9.6.13 The above information will support Decision Gate 2.
9.7 End To End Solution Options Development and Assessment Level 3 9.7.1 Following Decision Gate 2, technical designs that describe E2E Solution Options will be generated that will satisfy the CONEMP and detailed concept requirements from the Developing Concept Options stage. 9.7.2 Technical designs will be generated, or selected from MOD, Industry and Academia, as required, relevant to the concept being developed. An initial technical design shall be produced that describes an E2E Solution Option(s) in sufficient detail to support the generation of the Assessment Level 3 E2E Concept of Analysis (including a cost analysis of the concept across all DLoDs). 9.7.3 Further development to both E2E Solution Options design and E2E assessment methodology can be then developed in parallel.
9 The Office of Government and Commerce (OGC) defines a Benefit as: “The measurable improvement resulting from an outcome which is perceived as an advantage by a stakeholder” 10A Benefits map is a ‘Causal map showing the lines of argument between investment variables and value criteria, in which nodes represent benefits and links represent relatively direct causal relationships’.. UNCLASSIFIED
41 UNCLASSIFIED ANNEX A
9.7.4 Assessment at this level shall provide a more thorough and, where appropriate, quantitative E2E system level assessment. In particular, appropriate vignettes shall be developed (based the SAG scenario(s)) to test the E2E Solution Options over the appropriate DCPD cycle (or cycles). Due to the nature of this level of assessment it is expected that it would take much longer (6-12 months) to complete than previous stages, and the time taken will be dependent on the number of E2E Solution Options and the necessary complexity of the assessment. 9.7.5 Due to the diverse nature of concepts within ICS, no single tool or set of tools will provide the appropriate fidelity of E2E System assessment. Furthermore, this stage may also require experimental activities to provide either data or assessment validation. Therefore, in contrast to the other stages described in this document, the output of the E2E assessment cannot be described generically. Nevertheless, it is possible to identify some common elements that will be required. 9.7.6 The first activity at this Assessment Level is the generation of an Assessment Level 3 E2E Concept of Analysis (E2E COA) dependent on the: Nature of the concept under test; Fidelity of assessment required (this will also depend on the degree to which elements within E2E System have been assessed or validated by external activities; Time and resources available; Availability and applicability of extant models and tools. 9.7.7 The generation of a E2E COA will be informed by the preceding Benefits Mapping and Modelling activities in Assessment Level 2 and will involve: • Ensuring that vignettes are fit for purpose; • Identifying appropriate Measures of Merit (MOMs), including Measurements of ISTAR Effectiveness (MOIEs)11, Measurements of Performance (MOPs)12 and Dimensional Parameters (DPs)13; • Ensuring compatibility with ITEF guidance; • Specifying the nature of input data and ensuring assumptions are consistent. • Identifying the need for experimental activities; • Defining the fidelity of cost analysis required and the approach to generating the cost model. 9.7.8 A common element to the COA generation will be a Models Stock Take (to include models from the Authority, Industry and Academia) to ensure best use of extant modelling tools. 9.7.9 In some cases such models may either not exist or be available, and in such cases targeted modelling activities will be undertaken as appropriate by either Dstl or the Engine Room. 9.7.10 The COA should seek to link MOPs to MOIEs to Measures of Force Effectiveness MOFEs14 and seek to exploit extant Operational Analysis (OA) capabilities and activities, data and scenarios. 9.7.11 The Cost Analysis defined by the E2E COA will output an assessment of the financial impact of E2E Solution Options relative to each another and an ‘as is’ or baseline case. However it will not be required to provide:
11 MOIEs measure how well an ISTAR system accomplishes an assigned task within an operational context and is the ISTAR equivalent of Measures of C2 Effectiveness in the NATO Community of Best Practise (COBP)). An example MOIE may be the number of tasks or Intelligence Requirements satisfied. 12 MOPs: measure how well a system or force element accomplishes a defined task. 13 DPs are the properties or characteristics inherent in the physical systems or force elements. 14 MOFEs measure the degree to which a force meets its objectives. UNCLASSIFIED
42 UNCLASSIFIED ANNEX A
satisfy scrutiny prior to business case submission to the Investment Approvals Committee (IAC); Affordability recommendations. 9.7.12 Further assessment of the E2E Solution Options may be performed to develop an understanding of the cultural feasibility, as appropriate to the concept. 9.7.13 Decision Gate 3 will make the decision on how to proceed based upon the content of the E2E COA.
9.8 Demonstration to Stakeholders 9.8.1.1 A demonstration of E2E solutions will be undertaken, in order to demonstrate that the benefits that were identified in the Concept Capture stage are achievable. 9.8.1.2 This demonstration must be cognisant of the outputs of the Concept Capture stage and the demonstration must ensure that the stakeholders involved in the concept are satisfied that the E2E solutions have the ability to meets their needs. 9.8.1.3 This shall be an element of live Experimentation activities (Section 5.3).
9.9 Costed Interventions and Recommendations 9.9.1 During the E2E process, a good understanding of the concept will be developed, including its cost and scheduling impact, which should be used to influence future capability management by Cap ISTAR. 9.9.2 In order to ensure an effective handover of concepts from the research domain to the formal procurement by DE&S, at Decision Gate 4, the ICS programme will produce a set of costed interventions and recommendations to feed into the AOF process. The ICS interventions and recommendations should be in such a form that Requirements Managers can refer to them when generating their URD and SRD, including referring to the assessment strategy for understanding how the URD and SRD will be verified and validated.