MétaCan
Menu
Back to cohort
Record W2082911481 · doi:10.1109/dasc.2012.6382420

Optimizing an incremental Modular Open System Approach (MOSA) in avionics systems for balanced architecture decisions

2012· article· en· W2082911481 on OpenAlex

Why this work is in the frame

A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.

affAt least one author lists a Canadian institution in the pinned OpenAlex snapshot.

Bibliographic record

Venue2012 IEEE/AIAA 31st Digital Avionics Systems Conference (DASC) · 2012
Typearticle
Languageen
FieldEngineering
TopicSafety Systems Engineering in Autonomy
Canadian institutionsLockheed Martin (Canada)
FundersNaval Air Systems CommandBinghamton University
KeywordsModular designProcurementKey (lock)Systems engineeringAvionicsSoftware engineeringReuseComputer scienceEngineeringEmbedded systemOperating system

Abstract

fetched live from OpenAlex

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 3 <sup xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">rd</sup> party 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.

Full frame distilled prediction

Teacher imitation

Not calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.

metaresearch head score (Codex)0.002
metaresearch head score (Gemma)0.000
Version: codex-gemma-dda1882f352aValidation status: machine_predicted_unvalidated
Candidate categoriesMeta-epidemiology (narrow), Scholarly communication
Consensus categoriesnone
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Simulation or modeling · Consensus signal: Simulation or modeling
GenreCandidate signal: Empirical · Consensus signal: none
Teacher disagreement score0.810
Threshold uncertainty score0.999

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0020.000
Meta-epidemiology (narrow)0.0010.001
Meta-epidemiology (broad)0.0020.000
Bibliometrics0.0010.001
Science and technology studies0.0000.000
Scholarly communication0.0020.004
Open science0.0020.000
Research integrity0.0010.001
Insufficient payload (model declined to judge)0.0000.000

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.

Opus teacher head0.045
GPT teacher head0.251
Teacher spread0.206 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it