Optimizing an incremental Modular Open System Approach (MOSA) in avionics systems for balanced architecture decisions
Bibliographic record
Abstract
There is a need for incrementally optimizing the Modular Open Systems Approach (MOSA) being applied in open system based avionics platforms that include legacy and new capability architecture elements. To date, incremental improvements in MOSA based design methods have demonstrated additional cost reduction, sustainability, and new capability insertion benefits. This has been achieved by further addressing MOSA modularity, key interface standards, and standards conformance. The actual implementation of MOSA is typically guided by both customer-based procurement Statement-of-Work (SOW) language and supplier lessons-learned in execution of MOSA based programs. Implementation of MOSA has evolved and continues to change with regard best practices. New emerging government guidance on MOSA includes: increased government rights availability, encouraging increased competition in procurements, enabling reuse of pre-developed application software components, and sharing of common hardware developments across platform communities. Most MOSA programs are dealing with systems with multiple baselines: production, tech refresh, export derivatives, and future capability/opportunity extensions. Integrated MOSA programmatic and technical views can be a unifying element in assuring that the reference architecture decisions are balanced in near term solutions and life cycle benefits. This paper describes an incremental methodology for implementing MOSA based on lessons learned in execution of MOSA and current proactive MOSA initiatives. The methodology includes a compliance assessment of MOSA application, integration of capability and technology planning roadmaps, comparative assessment of legacy and emerging open/key standards, and factoring emerging key interfaces into proactive MOSA based planning. Any architecture by definition includes a set of hardware and software components, hardware and software standards, and a topology instance. Typical MOSA architecture work products generated in this regard include a MOSA Plan, a Platform Technology Insertion Plan, Platform/Technology Planning Roadmaps, and an End-Of-Life (EOL) Management Plan. Relative to architecture, the commercial world continues to introduce next generation hardware components, software components, and standards at a very rapid rate. A key MOSA driver is to organize an infrastructure of key interfaces for establishing sustainable modularity, standards, and interoperability to enable programs to make balanced architecture decisions. This MOSA implementation has been successfully applied on the Navy Multi-Mission Helicopter (MMH) program. Optimizing MOSA in avionics systems is a continuous program commitment from both a customer and supplier perspective. Additional MOSA optimization opportunities are continuously emerging including initiatives like the Future Airborne Capability Environment (FACE). The objective of FACE is to guide current MOSA platforms toward a more unified next generation processing environment with additional improvements in open, modular, portable, partitioned, expandable, secure, and interoperable platform architectures. Additional drivers include the need for improvements in platform information assurance, tamper resistant and trusted computing, affordability in incorporating advanced program capabilities, and support of 3rdparty rapid capability insertion. Proactive MOSA optimization focus and proactive engagement in initiatives like FACE are critical to future platform affordability and sustainability in balanced architecture solutions.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.006 | 0.009 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.002 | 0.003 |
| Open science | 0.001 | 0.003 |
| Research integrity | 0.001 | 0.002 |
| Insufficient payload (model declined to judge) | 0.003 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".