Status changed from status: Open to status: Closed.

Description information changed.

Summary of Q&A Changes

New Question Added (Q1): Three questions about GFI availability for non-priority systems, co-hosting vs. separate system hosting architecture, and hardware profile recommendations with environmental constraints in Phase I.

Questions Renumbered: Previous Q1-Q5 shifted to Q2-Q6 due to new Q1 insertion.

Key Change: The updated Q&A introduces more granular scope questions around multi-system integration and hardware architecture decisions, while maintaining all previous answers unchanged. New Q1 seeks clarification on whether Phase I must analyze all six systems in detail or accept portfolio-level characterization where GFI is limited, and whether OLYMPUS should support co-hosted functions or primarily standardize interchangeable hardware.

Q&A Changes Summary

New/Updated Answers:

• A1 (NEW): Detailed legacy computing environment specifics—VME-era processing, VxWorks components, mixed Linux/Windows (transitioning to Linux-only), significant C codebase. Confirmed system boundary excludes topside RF front-ends. Clarified safety re-qualification required upon fielding, but full standards implementation not required for Phase I prototype.

• A2 (NEW): Emphasized architecture is open for definition with existing standards requiring justification. Unification is primarily interface-focused initially, with goal toward common parts for logistics. Clarified ITAR constraints apply only to foreign persons accessing controlled technical data; no blanket citizenship restrictions beyond standard export-control rules.

• Q5-Q7 (COMPLETE): Full answers provided to architecture definition, representative interfaces, simulation approach, performance metrics (12ms latency, 5Hz frequency), and security considerations. Confirmed software-centric approach acceptable with representative hardware.

Key Clarifications:

• Linux-only target environment (no Windows)
• Phase I can use simulated systems and representative interfaces
• 12ms latency requirement, ~5Hz data rates
• No specific MOSA standard mandated; selection must be justified

Summary of Q&A Changes

New Questions Added (2):

• Q1: Technical specifics on legacy systems (AN/SPN-35C/46 computing environment, processor architecture, OS, languages; system boundary definition; safety-of-flight re-qualification expectations)
• Q2: MOSA standard conformance (FACE/SOSA/HOST), unification scope, incumbent system replacement, and ITAR citizenship/residency constraints

Result: Added 4 substantive new questions addressing technical architecture details, compliance standards, and security requirements not covered in previous Q&A. No existing answers were updated; new questions received no responses yet.

Updated Answer to Q1: Clarified that "emulating" SPN-35 requires modernizing software into containerized environments for cyber compliance, not just minimal modification. Added that GFI will include source code and interface documentation provided as needed. Refined architecture selection guidance: prefer existing MOSA if acceptable, but develop new architecture if necessary rather than compromise.

Added new Q1 with 3 sub-questions clarifying SPN-35 priority system requirements: whether "emulate" means rehosting/recoding vs. running legacy binaries; what SPN-35 GFI (source code, binaries, documentation, test data) will be provided; and whether Phase I should evaluate existing MOSA architectures or develop new ones. Previous Q&As renumbered accordingly.

Q4 now has an answer: Representative hardware is acceptable for Phase I. The architecture must support easy hardware changes over time, with initial prototypes included in the scope.

Summary

This Q&A clarifies that Phase I performers have flexibility to use representative/simulated shipboard systems and can define their own architecture within broad OLYMPUS objectives, rather than being constrained by existing government-defined standards—allowing broader technical approaches but requiring applicants to clearly justify their architectural choices and demonstration strategy.

Status changed from Pre-Release to Open

New opportunity: Open, Layered, Yielding Modular Platform for Unified Systems