Home / Architecture
Væringjar II · Research architecture

Separate mission intent from damaged hardware.

The architectural hypothesis uses hierarchical abstraction so that a change at the physical-resource level can be propagated upward, while a new mission-feasible configuration is derived downward.

Four abstraction levels

Reason about capability across layers.

Damage originates in physical resources, but its consequence is functional and mission-level. The architecture separates these concerns so post-failure reasoning does not depend on one fixed physical implementation.

Mission layerObjectives, priorities and minimum acceptable outcomes for the current situation.
Function layerFunctions, their criticality, degradation states and resource dependencies.
Service layerRuntime mapping, execution modes, communication and software/platform services.
Resource layerActual post-failure state of sensors, actuators, compute, networks, energy and physical components.
Four-level abstraction hierarchy from the survivability research

Research-origin diagram from the supplied survivability manuscript; retained here as scientific evidence rather than a marketing illustration.

Important distinction

Two hierarchies, two different jobs.

Abstraction hierarchy

  1. Mission — admissible mission outcome and minimum functionality.
  2. Function — active, standby, degraded and disabled functions.
  3. Service — runtime mapping and selectable software/platform configurations.
  4. Resource — measured physical/logical operability \(\boldsymbol{\rho}(t)\).

Control-execution hierarchy

  1. L3 Mission Manager — \(10\,\mathrm{Hz}\), planning and resource allocation.
  2. L2 Supervisor — \(100\,\mathrm{Hz}\), fault detection and mode switching.
  3. L1 Servo Control — \(1\,\mathrm{kHz}\), torque/position regulation.
  4. L0 Hardware — \(10\,\mathrm{kHz}\), sensor/actuator interface and interrupts.
The first hierarchy answers what capability remains?; the second answers where and how fast is the control action executed?. They are complementary, not alternative descriptions of the same layers.
Information flow

Damage propagates upward. Reconfiguration is decided downward.

↑
State propagation

Resource degradation changes service availability, functional feasibility and ultimately mission capability.

↓
Decision propagation

Mission priorities constrain which functions are retained and how services are remapped to the resources that remain.

↺
Closed-loop supervision

The architecture repeatedly evaluates whether the selected configuration remains feasible as the damaged state evolves.

Supervisory sequence

Architecture-level decision before controller adaptation.

01ObserveCollect post-failure resource and dynamic-state information.
02InterpretEstimate residual operability and functional consequences.
03ConfigureSelect a mission-feasible mapping of functions and resources.
04AdaptSelect or synthesize control laws appropriate to the changed plant.
05VerifyContinue only while safety, stability and minimum mission constraints hold.
Adaptive reconfiguration sequence from the survivability research
Scientific status

The architecture is a research result under implementation.

The current work is to turn the conceptual layers and reconfiguration sequence into explicit software boundaries, data models, interfaces and executable decision logic.

The implementation should remain traceable to the research assumptions so that experimental results can validate or reject specific architectural mechanisms.

Evidence

See the publications behind the architecture inside the research library.

Publication status is shown explicitly: published, submitted / under review, preprint or research manuscript.

Research publications →