RFI D2TA DRAFT.pdf

Design to Transition Accelerator (D2TA)

Request for Information (RFI)

1. SCOPE:

This document is intended to gather information only and does not constitute a solicitation or directly lead to an award process.

U.S. technological dominance in microelectronic (ME) materials, processes, devices, and architectural designs can only be sustained through the development of a robust domestic innovation ecosystem that fosters the rapid development and transition of novel concepts into commercially viable manufacturing processes.

In recent years, U.S. chip innovation has been threatened as next-generation hardware technologies have become increasingly reliant on offshore sources for State of the Art (SOTA) as well as State of the Practice (SOTP) manufacturing, prototyping, and innovation. This trend creates significant hurdles for domestic microelectronics innovators. The dearth of development infrastructure -- from design phase through prototyping -- has resulted in a dramatic tapering of U.S. centric hardware startups/innovation. The remaining U.S.-based technology startups have been forced to transition emerging microelectronics capabilities into off-shore ecosystems.

To address these challenges, the Department of Defense (DoD) will pursue a multifaceted approach to strengthen the domestic microelectronics ecosystem.

The Government is seeking information based on the completeness of the below outline to determine the best and most practical solution to bolster the community. The contractor should answer the following questions to best facilitate the Government’s approach.

i. What hierarchy overview/processes or information is missing from the technical approach to fully develop a Defense Digital Engineering Integrated Infrastructure Environment?

ii. What are the risks or issues with the current hierarchy overview/process for technical approach as described?

iii. What current capabilities does the responder have that meet the technical approach as described or that would add to the technical approach?

iv. What technical gaps are missing within hierarchy overview/process technical approach?

2. Definitions and Acronyms:

ATO refers to Authorization to Operate.

DRAFT

Digital Engineering Infrastructure (DEI) is a Government Owned Contractor Operated (GOCO) system comprised of:

• Electronic Design Automation (EDA) tools hosted on cloud computing infrastructure.

• Microelectronics emulation hardware.

• Secure repository hosted on hybrid cloud computing infrastructure.

• Integration Environment for integrating different EDA tools and emulation capabilities to create program specific workflows and processes.

• Software based Orchestration with the ability to scale.

Design Pedigree refers to the validation of the composition and provenance of technologies, products, and services. Pedigrees increase the assurance that the claims suppliers assert about the internal composition and provenance of the products, services, and technologies they provide are valid.

Design Provenance refers to the records describing the possession of, and changes to, constituent elements of the component under development (e.g., IP, components, chipset, processes, information, systems, organization, and organizational processes). Provenance enables all changes to the baselines of the element under development, to be reported to DEI or component users.

A digital thread traces the interconnection of virtual elements and analyses to that realized in the physical world along with the provenance and pedigree of the elements. D2TA requires the digital thread to include the revision history (change, date, user) for the digital twin.

A Digital Twin includes all design source code (e.g., RTL, SPICE), models, scripts, test suites, test data, tools, software, operating systems, and versions, required to modify, reproduce, and manufacture a design.

Emulation refers to hardware accurate modeling and simulation and virtual analysis. D2TA is focused on utilizing the highest fidelity emulation capabilities available.

GOCO refers to government owned, contractor operated.

An Objective Requirement represents the desired operational goal associated with a performance attribute beyond which any gain in utility does not warrant additional expenditure. Objective requirements are represented as (O) in this document.

PoR refers to a DoD Program of Record.

A Project refers to a D2TA activity. It may be managed by a PoR, a DoD Component, a DoD Service laboratory, the D2TA program, or other organization as authorized by D2TA.

A Technical Data Package is the authoritative technical description of an item that supports the item lifecycle. It contains the required design configuration, performance requirements, and procedures to ensure adequacy of item performance. It consists of applicable technical data such as models, engineering design data, associated lists, specifications, standards, performance requirements, quality assurance provisions, software documentation and packaging details.

D2TA provides a tailored version of MIL-STD 31000B for each program Element in Attachments B, C, D, and E.

A Threshold Requirement represents the minimum acceptable value for performance or functional requirements. For cost and schedule requirements, the threshold requirement represents the maximum allowable values. Threshold requirements are represented as (T) in this document.

3. REQUIREMENTS:

3.1 Technical Approach:

3.1.1 The responder is to provide an estimate of manufacturing capacity for each process within an Element.

3.1.2 For each Element the contractor responds to, a specification table should be provided for each process within the element.

3.1.3 The following additional information is to be supplied in the response:

3.1.3.1 Description of the contractor's existing manufacturing capabilities.

3.1.3.2 Estimate of starting Technical Readiness Level (TRL) and what TRL is expected once the capability is fully qualified.

3.1.3.3 Description of the contractor's existing business (e.g., ownership structure, total revenue, % commercial, % defense, etc.).

3.1.3.4 Description of other investments that are being leveraged in connection with this effort (e.g., local/state/federal government incentives, contractor investments, etc.).

3.3.4 Element 1: DoD Enterprise Microelectronics Digital Engineering Infrastructure

(DEI)

The intent of Element 1 is to construct and operate a DEI that serves as a DoD enterprise platform for Microelectronics Digital Engineering virtual development and analysis activities, including the development and maturation of IP, components and chipsets across DoD Components and PoRs.

This Element assumes that the DEI implements a software-based hybrid-cloud architecture and orchestration with continuous DevSecOps procedures demonstrated within the system.

The DEI sought under D2TA explicitly seeks implementation of multiple DoD Security levels within a common environment, allowing secure DoD analyses to be performed against data sources used for non-DoD manufacture. The multi-security common environment must maintain both DoD security of the analysis and confidence that data sources used for the analysis and the non-DoD manufacture are the same. Users will perform classified analysis utilizing common, unclassified data.

Commonality and portability of data is an essential tenet for proliferation of common architectures and devices, and for the D2TA program.

Develop and maintain a cloud and EDA vendor agnostic DEI architecture.

Implement, operate, and maintain the DEI.

Develop and execute a plan to increase the security level of the existing solution and acquire mission (not provisional) Authorization to Operate (ATO) approvals to Impact Level 4 (IL-4), Impact Level 5 (IL-5), Impact level 6 (IL-6), TS, TS SCI, and Systems Applications and Products (SAP) environments within 60 months.

Develop a plan to enable ATO approvals to IL-4, IL-5, IL-6, TS, TS SCI, and SAP environments for DoD Program of Record use.

Develop and identify technical milestones as part of the development plan.

Develop a business model delineating cost of compute, operating pipelines, hybrid-cloud connectivity, security connectivity (cross domain) and support for continuous ATO evaluation and upgrade.

Define and implement processes and dashboards for project startup, monitoring, and closeout/archiving.

Develop and implement a 24/7 support model and environment capable of handling service calls at scale.

Develop and implement process for performing DevSecOps maintenance including cyber-security updates, functionality/security patches, and obsolescence management for both software and hardware integrated into the DEI.

Acquire cloud services at best rate available to government.

At each milestone, update and deliver a technical data package (TDP) for the DEI that includes all information required for a third party to independently implement and operate the DEI. The TDP is to be in accordance with MIL-STD-31000B. The TDP includes hardware and software bill of materials, business processes, business plans, test plans, test procedures, test results, action lists, and any other data required to meet the requirements of this SOW.

Identify and document all elements the offeror considers proprietary and provide mechanism to permanently partition these elements in the DEI. This activity must be completed prior to contract award.

Develop and implement a workforce development and retention plan that establishes a sustaining pipeline of talent.

Establish NDA and other agreements with Element 2 contractors to provide data and access required for independent assessment of the DEI.

Update the EDA tools within the DEI as directed by the Government. The government anticipates updates occurring on initiation of a project and subsequently on a quarterly basis.

Sustain legacy DEI infrastructure utilized on all projects executed with DEI, including legacy EDA tools and hardware. Digital twins constructed on the DEI is to be able to reconstructed at a later date from a Digital Thread using the same tool versions and specialized hardware used in earlier (including pilot) development activities. The DEI infrastructure will maintain prior versions of EDA tools with government rights to use in future.

DEI Objective: The DEI is to be Authorized to Operate

The DEI security and ATO boundary includes all licensed EDA tools, emulation capabilities, secure repository, cloud computing services, testing capabilities, scripting or programming frameworks, and ATO plan. (T = O)

The DEI architectures support multiple classification levels, Controlled Unclassified Information (CUI), ITAR, Secret, Top Secret (TS), Sensitive Compartmented Information (SCI), and SAP.

(T=O)

The DEI is ATO at program relevant security levels (impact levels) across the Tri-Service (Army, Navy, and Air Force). (T) The Offeror is to be develop a plan to support access at program relevant security levels (impact levels) across DoD Components, Federally Funded Research and Development Centers (FFRDCs), University Affiliated Research Centers (UARCs), industry, small businesses. (O)

The DEI and DEI ATO is to support hybrid cloud implementations, specifically those that integrate project specific on premise and cloud vendor hosted implementations. i.e., on-premises compute assets must reside within the ATO boundary. (T=O)

The DEIs facilitate remote access from government, contractor and commercial systems consistent with the security requirements of any given impact level. (T=O)

The DEI ATO defines an authorization to connect (ATC) procedure to support programs’ hybrid cloud implementations. i.e., a procedure to secure, accredit on-premises compute assets within the ATO boundary. (T=O)

Commercial cloud services utilized within the DEI uses FedRAMP approved hardware and software services. (T=O)

DEI Objective: The DEI supports multiple concurrent projects.

The DEI supports multiple concurrent DoD projects scalable to arbitrary number of projects and sites, each with potentially multiple organizations with multiple users working across potentially multiple sites. (T=O)

The DEI implements authorization and access controls and enforce security at user, site, organization, and project levels. (T=O)

The DEI allows each project to configure authorization and access for the project’s users, sites, and organizations within the project. (T=O)

The DEI allows each project to define a design flow for the project that identifies which EDA tools and versions each user, site, and organization is allowed to use. (T=O)

The DEI, for each project, enforces the design flow and associated restrictions defined by the project. (T=O)

The DEI develops a business model to address long-term expansion and transition to broad use at every security level for PoRs and project engagements. The business plan should be informed by and responsive to information collected during execution across all Elements. (T=O)

DEI Objective: Scalability and Persistence

The DEI is to be scalable on demand. (T=O)

The DEI is to be persistent across the full lifecycle of each project and across the full lifecycle across all programs. The DEI develops and demonstrate support of development, archive and restoration of projects. (T=O)

The DEI retains design provenance for each project in perpetuity. (T=O)

DEI Objective: Multi-Vendor Support

The DEI architecture is to be EDA tool vendor agnostic. (T=O)

The DEI architecture is to be cloud service provider agnostic. (T=O)

The DEI architecture does not provide any inherent or implicit advantages to any EDA tool vendor or cloud service provider. (T=O)

The DEI architecture supports EDA tools from multiple vendors, specifically all tools licensed by the DoD for enterprise use and those licensed for program specific use within the DEI. (T=O)

The DEI supports all emulation hardware acquired by and licensed for DoD use within the DEI.

(T=O)

The DEI supports the use of cloud computing services acquired by the DoD for use within the

DEI. (T=O)

The DEI supports scripting and programming frameworks for implementing design flows that integrate tools and emulation capabilities from different vendors and across different cloud service providers. (T=O)

DEI Objective: Secure Repository

The Secure Repository stores design provenance across the full lifecycle of each project. (T=O)

The Secure Repository logs user accesses to designs or components thereof, including any intellectual property or module. (T=O)

The Secure Repository stores design provenance across multiple projects and their lifecycles to facilitate DoD-wide access and reuse. (T=O)

The Secure Repository provides facilities to capture the Digital Thread and curate data within the repository for long term storage and archival. (T=O)

The Secure Repository maintains traceability, provenance, and cross-site data management for legally controlled data files such as Intellectual Property, PDKs, etc. (T) The Secure Repository maintains traceability, provenance, and cross-site data management for all elements of the TDP or other, program-designated artifacts. (O)

DEI Objective: Intellectual Property (IP)

The Secure Repository stores IP modules, ownership, license terms and conditions, revision history, and access history. (T=O)

The DEI stores IP modules in the Secure Repository in encrypted form. (T=O)

The DEI restricts access to IP, decrypting only for uses authorized under the relevant license terms and conditions. (T=O)

The DEI supports a structured data model that serves as an IP catalogue to include licensing terms and conditions, and pricing of IP access. (T=O)

DEI Objectives: Other

The DEI monitors and track EDA tool, IP, and cloud service usage at the project, site, organization, and user levels. (T=O)

The DEI provides usage statistics to support project and DoD-wide accounting, billing, and auditing purposes. (T=O)

The DEI identifies and complies with all relevant cybersecurity and protection regulations and standards required to obtain corresponding ATO approvals. (T=O)

The DEI supports registration of users in the System Network Approval Process (SNAP) IAW the Defense Information System Network (DISN) Connection Process Guide and Joint Force Headquarters-DoD Information Network direction.

The DEI support provides capabilities for Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). (T=O)

The DEI support Containers as a Service (CaaS) such that users can run an application and all its dependencies in isolated containers. (O)

Element 2: Independent, Continual Assessment of Digital Engineering Infrastructure

The intent of Element 2 is to validate the ability of a reasonably qualified 3rd party to reconstruct, reconstitute, and operate the DEI established in Element 1. The contractor will establish and implement continual, independent assessment of the Digital Engineering Infrastructure (DEI) to improve cyber security, quality of service, efficiency, and to refine the business model for operating the DEI. One or more contractors may be selected for this Element.

The contractor assesses the ability of a reasonably qualified 3rd party to reconstruct, reconstitute, and operate the DEI. (T=O)

The contractor evaluates and recommends modifications to the DEI business model to most effectively address long-term expansion and transition to broad use at every security level for PoRs and project engagements. (T=O)

The Contractor establishes NDA and other agreements with the Element 1 contractor that provide access to DEI data and capabilities needed to independently assess DEI cyber security, quality of service, efficiency, and business model. (T=O)

The Contractor develops, implements, and utilizes automation to support cyber monitoring, penetration testing, and system performance and resilience assessment. (T=O)

The Contractor utilizes the Element 1 TDP to build a sub-scale replica to conduct independent testing and evaluation of the DEI architecture and implementation. The contractor demonstrates the ability of a reasonably qualified 3rd party to reconstruct, reconstitute, and operate the DEI (T=O)

The Contractor develops an implementation plan to conduct independent assessments of the DEI for different security and authorization (ATO) levels to include IL-4, IL-5, IL-6, TS, TS SCI, SAP. (T=O)

The Contractor creates and delivers to the Government the TDP for any automation or tools developed for or used in its Element 2 execution. (T=O)

The TDP includes all data, software, and tools needed for a third party to independently build and operate the assessment tools used in Element 2. (T=O)

The Contractor collects business data, audit logs, and other information to support DEI business model analysis. (T=O)

The Contractor independently assesses the cybersecurity of the DEI developed under Element 1, including hardware and software vulnerabilities and mitigations. (T=O)

The Contractor identifies susceptibility of environment to hardware failures, software failures, distributed denial of service (DDoS) attacks, etc. (T=O)

The Contractor identifies and collects data needed to assess DEI operations, performance metrics, ease of use by trained practitioner, and security. (T=O)

The Contractor independently monitors and assesses DEI system efficiency, quality of service, and performance including orchestration and operation. (T=O)

The Contractor recommends modifications to the DEI to address cyber/physical deficiencies, improve system resilience, and enhance quality of service. (T=O)

Objective: Independent assessment

The independent assessment topics will focus on three primary areas: Cyber Resilience, Operational Availability, and Adaptability. The contractor will periodically evaluate the DEI for the areas and recommend improvements to the DEI that increase its robustness. The desire is for assessment to be as automated as possible, enabling continuous assessment of the DEI.

Objective: Cyber Resilience

The contractor periodically provides a list of cyber characteristics / properties the DEI has implemented including: Authentication, Authorization, and Accounting (AAA); audit mechanisms, forensics, logging, intrusion detection / prevention, data exfiltration, and data integrity.

The contractor evaluates the robustness of the cyber characteristics implemented in the DEI against previous, current, and evolving cyber threats.

The contractor recommends improvements to the implementation of the DEI for increased resilience to cyber threats.

The contractor provides a plan to identify, evaluate, and recommend improvements to the cyber characteristics of the DEI.

Objective: Operational Availability

The contractor periodically identifies the hardware, software, and networking components implemented in the DEI that affect operational availability.

The contractor monitors the DEI implementation and evaluate recovery times for operational failures and construct an objective evaluation of the operational availability of the DEI.

Monitoring includes operational availability effects and responses to Defense Information Systems Agency (DISA) protocol modifications or requirements changes.

The contractor recommends improvements to the implementation of the DEI to increase operational availability rate along with financial implementation cost analysis.

The contractor provides a plan to identify, evaluate, and recommend improvements to the operational availability of the DEI.

Objective: Adaptability

The contractor evaluates the comprehensiveness of the DEI Technical Data Package provided by the Element 1 contractor.

The contractor evaluates the effort required to adapt the DEI implementation to a different cloud service provider.

The contractor provides a plan for periodic evaluation of the TDP and adaptability of the DEI.

Element 3: Electronic Design Automation Tools, Intellectual Property, and Services

The intent of Element 3 is to provide EDA Tools and IP licenses along with relevant professional services directly to the government for DoD and associated contractor use with established, well-defined costs and unambiguous terms and conditions. The tools, licenses, and services are anticipated to be restricted to prototype development (less than 1,000 devices produced), verification, analysis, and digital twinning efforts.

DoD safety and security requirements often require insight into, and verification and validation of IP integrated into DoD systems. Offeror is encouraged to provide full visibility and auditability of the licensed IP.

Potential vendors may provide one or more of the following offerings:

• EDA and emulation tools for developing and verifying electronics.

• Intellectual property (IP) configuration, customization, and licensing.

• Professional services including microelectronics training development, instruction, design, and analysis.

Objective: Professional Services Requirements

Vendor provides predefined pricing for professional services. (T=O)

Professional services personnel are to be U.S. citizens. (T=O)

Design and analysis personnel is to be clearable to appropriate levels as needed by specific programs at ITAR, Secret, Top Secret, and SCI. Pre-cleared personnel are highly desirable(T=O)

Objective: Licensing Terms and Conditions

EDA Tool license terms and conditions includes the right to use the tools to produce up to 1,000 devices (prototypes). (T=O)

EDA Tools is to be acquired on a 3-year fixed cost, flexible use terms and conditions that permit use across board, package, chip and transistor level of design, verification, and analysis. (T=O)

EDA Tool license terms and conditions includes a plan for upgrade and maintenance of all EDA Tools. (T=O)

EDA Tool license terms and conditions includes the rights to escrow and use obsoleted tool or deprecated tool versions on the DEI. Obsolete tool licensing is assumed to depend on current purchase agreements. (T=O)

EDA Tool licenses includes rights to use across multiple sites, cloud services, wide area computer networks, and classified venues including “air-gapped” systems.

EDA tool licenses includes provisions for usage-based costing and consumption of fixed-value purchase. (e.g., EDA card model) (T=O)

Intellectual Property license terms and conditions provides access to a comprehensive IP catalog with pre-defined fixed rate, usage-based for DoD wide access to prototype volume licenses.

(T=O)

Intellectual Property license terms and conditions includes pre-defined pricing for production uses. (T=O)

All IP licenses includes ability for DoD and its contractors to verify and validate IP, including under DoD operational environments. (T=O)

All Intellectual Property licensing includes full inspection rights. (T=O)

Intellectual Property providers supports an agreement-based access model. (T=O)

Intellectual Property providers develops a structured data model that includes all IP and serves as IP catalog, to include identification of IP, terms, conditions and pricing in accordance with DEI requirements. (T=O)

IP license terms includes ability to escrow any IP utilized by DoD or its contractors as part of this program for on the DEI. (T=O)

No intermediaries for licensing

All EDA tools is to be licensed directly to the DoD with rights to use across all DoD Components. (T=O)

All IP is to be licensed directly to the DoD with rights to use across all DoD Components. (T=O)

All emulation hardware is to be sold or leased directly to the DoD. (T=O)

EDA Tool Coverage

Vendor provides a comprehensive set of licensed capability from their commercially available EDA/CAD tool catalog and flows. Tools and tool flows of interest are identified in Table A.

Element 4: Digital Engineering and Design Acceleration Pilot Projects

Requests for potential pilot projects will be initiated according to Service Priority.

Requests or calls for potential pilot projects will go out to DoD, including DoD Component Headquarters, DoD PoRs, FFRDCs, UARCs, and relevant DoD Communities of Interest. PoRs or projects will engage contractors as relevant.

Pilot projects may address varying levels abstraction, including IP, devices, chipsets, and printed circuit boards.

The intent of IBAS funded DE pilot projects is to

• Enhance the use of virtual analysis and modern architectures in PoR microelectronics development. (T=O)

• Increase the effectiveness of modernization opportunities within existing PoR electronics systems (e.g. utilizing MOSA, common architectures). (T=O)

• Reduce the burden of sustainment for long-life PoR systems including mitigation of obsolescence through use of common / domain specific architectures. (T=O)

The intent of T&AM funded Design Acceleration pilot projects is to

• Develop components or chipsets for use across multiple PoRs (T) and services (O) (e.g., domain specific architectures)

• Accelerate the fielding of these components or chipsets into DoD systems. (T=O)

Common Criteria for IBAS and T&AM Pilot Projects

Pilot projects demonstrate Program of Record (PoR) engagement and commitment

• One or more PoRs must provide documented support to the pilot project. (T=O)

• The relevant PoR(s) will commit funding and / or personnel towards executing the pilot project. (O)

• Supporting PoR(s) must commit to utilizing delivered digital twin within the context of their program. (T=O)

Pilot projects apply microelectronics digital engineering tools and practices, including but not limited to:

• Demonstrate use of Commercial Best Practice tools and methodologies. (T=O)

• Negotiate and acquire access to and maintain the Technical Data Package including any underlying intellectual property (IP). (T=O)

• Operate the pilot activity on the Digital Engineering Infrastructure (DEI) to the extent possible (T=O).

• Developing virtual analysis-based digital twin models to develop, capture, validate, and verify designs, including hardware-software co-design, integration, verification, and validation. (T=O)

Pilot projects deliver a digital twin for the device or analysis that:

• Can be integrated into the next higher-level assembly digital engineering efforts. (T=O)

• Serves as a digital specification and model of the planned component. (T=O)

• Facilitates analysis across the entire ME lifecycle including development, manufacturing, testing, and operations and maintenance. (T=O)

• Defines and include mechanism(s) to support aid PoR decision making (T=O)

• Captures the digital thread, and includes identification of each constituent element (e.g., hardware, IP, embedded software, etc.) and its provider (T=O)

• Captures all artifacts required to support IV&V. (T=O)

Pilot projects develop and implement a PoR(s) approved plan to accelerate fielding of the ME device that:

• Identifies development reviews and functional demonstrations. (T=O)

• Leverages the digital twin for the component to extent practicable. (T=O)

• Includes DT&E and OT&E activities. (T=O)

• Includes any necessary certifications or endorsements. (T=O)

Pilot projects develop and implement a plan of objective assessment of success that:

• Establish metrics (Metrics) for assessing impacts of digital engineering prior to starting execution. (T=O)

• Assess and measures impacts of digital engineering approach based on the Metrics.

(T=O)

Objective: Digital Engineering Pilot Project Criteria funded under IBAS

The pilot project directly addresses development, modernization, sustainment, and/or obsolescence issues for supporting PoRs. (T=O)

If the pilot project is successful, the PoRs commits to broader implementation of digital engineering for microelectronics (beyond the pilot). (T=O)

The pilot project provides a document of what was done, how it was done, and key findings including impacts to cost, schedule, risk, or other metrics used and any potential improvements to best practices. (T=O)

Objective: Design Acceleration Pilot Project Criteria

The pilot project focuses on developing or maturing an architecture, design and verification, manufacturing, post-silicon validation, or program insertion activities.

The pilot project identifies, for each PoR, the system engineering context within which the digital twin or reusable module will be integrated.

The contractor develops and implements a ME component specification that:

• is approved by sponsoring PoR(s) and D2TA program. (T=O)

• includes environmental and reliability requirements. (T=O)

• includes relevant assurance requirements. (T=O)