Open, Layered, Yielding Modular Platform for Unified Systems

# 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