Skip to content
Hamilton Archive
0 / 17
Pre-launch Review

Universal Systems Language for Preventative Systems Engineering

Universal Systems Language for Preventative Systems Engineering

Section titled “Universal Systems Language for Preventative Systems Engineering”

Margaret H. Hamilton and William R. Hackler, Hamilton Technologies, Inc., 2007

The paper introduces 001AXES as a universal systems language created to address problems “considered next to impossible to solve” with traditional approaches. The Apollo empirical study is summarized with the canonical error statistics: approximately 75% interface errors, 50% of budget on simulation, 44% found by manual means, 60% latent across previous flights, no software errors during actual flights.

From analysis of interface error categories, “a mathematical theory was derived for defining systems such that the entire class of interface errors would be eliminated.” The key insight: “systems are asynchronous in nature and this should be reflected inherently in the language used to define systems.” Events occur when objects interact, and by describing these interactions the schedule of events is inherently defined.

The DBTF Paradigm

Section titled “The DBTF Paradigm”

Traditional approaches are characterized as “curative” — testing until errors are eliminated. DBTF is “preventative” — errors are not allowed in the first place. Correctness is accomplished by built-in language properties “into the grammar.”

Every object is a System Oriented Object (SOO), integrating all aspects of a system: function, object, and timing. “Every system is an object; every object is a system.” 001AXES is a meta-language — “mechanisms to define mechanisms for defining systems” — that is semantics-dependent but syntax-independent. Every syntax shares the same semantics.

The Six Axioms of Control

Section titled “The Six Axioms of Control”

The axioms are presented in their most detailed published form:

  1. Axiom 1 (Invocation): A parent controls invocation of its immediate children only. The parent cannot invoke itself, its own parent, non-immediate descendants, or siblings.

  2. Axiom 2 (Output responsibility): A parent controls responsibility for elements of only its own output space. Decomposition stops when primitive types are reached.

  3. Axiom 3 (Output access rights): A parent controls output access rights for each immediate child. Outputs are traceable instance by instance.

  4. Axiom 4 (Input access rights): A parent grants read-only domain access to children. The parent cannot alter its own domain. Combined with Axiom 3: output variables of a function cannot be input variables of that same function.

  5. Axiom 5 (Error detection): A parent controls rejection of invalid elements of its own input set. Must detect and ensure rejection of inputs not in its domain.

  6. Axiom 6 (Ordering): A parent controls ordering (including priority) of the immediate lower level. Priority determines precedence for concurrent processes. A process cannot interrupt itself or its parent.

Derived theorems: Every object has a unique parent, is under control, and has a unique priority. Dependent functions exist at the same level. Single reference/single assignment property holds. Every system is event-driven. Every system is ultimately definable in terms of three primitive control structures.

Primitive Structures

Section titled “Primitive Structures”
  • Join: Parent controls children to have a dependent relationship. Sequential execution with data flow between siblings.
  • Include: Parent controls children to have an independent relationship. Potential parallel execution.
  • Or: Parent controls children to have a decision-making relationship. Selection based on a partition function.

These structures eliminate all interface errors (75—90%) at the definition phase. They have special significance for real-time distributed systems: event-interrupt-driven behavior; each object traceable, reconfigurable, with unique priority; independencies and dependencies detectable for parallel and distributed processing.

User-Defined Structures

Section titled “User-Defined Structures”

This paper provides the most detailed published exposition of derived structures:

Interrupt structure. Uses is:present(i) evaluated asynchronously. When an interrupt signal is available, the interrupt handler executes; otherwise, the primary function continues and the check repeats. Execution snapshots (EMaps) show how this plays out over time, demonstrating the interrupt granularity based on function completion time.

Periodic structure. Repeated scheduling of a function within a time period. Uses run:timer(et)=end for timing and when:all,present for synchronization. Functions execute asynchronously and event-driven; the timer does not block continued processing.

GN&C Application. Guidance, navigation, and control using the periodic structure, with priority nesting: control has higher priority than guidance, which has higher priority than navigation. The ci structure (derived from Include) establishes the priority ordering. “Any number of processors can be added without rewriting the application because scheduling is built-in.” The getPut structure provides access and security between databases.

Jset structure. A recursive universal structure usable in both TMaps and FMaps. Produces co-dependent patterns of type T with zero, one, or two other T elements. Applied to a cars TMap type and a largestCar FMap function, the structure demonstrates recursive processing with the next relation and a partition function gt (greater than). The recursive type traversal stops at is:Null.

Universal Primitive Operations

Section titled “Universal Primitive Operations”

TMaps provide operations inherited by all types: create, destroy, copy, reference, move, access value, detect/recover from errors, access type, access instances. TMap and OMap are themselves available as types, enabling self-reflective systems.

Spatial control properties ensure that two objects cannot occupy the same place at the same time, and reject values exist in all types for error recovery.

Automation and Self-Generation

Section titled “Automation and Self-Generation”

The 001 Tool Suite provides requirements analysis, simulation, automatic code generation, and automatic self-generation. “001 is defined with itself and automatically generates itself.”

The 001DXecutor — a distributed runtime execution engine — forms a hierarchy managing resources and communicating via TCP/IP. Hamilton estimates that approximately 80% of the UML2 specification standard could be eliminated with a 001AXES DXecutor active object substrate.

The Preventative Hierarchy

Section titled “The Preventative Hierarchy”

The paper closes with the hierarchy in its most compressed form: “finding a problem statically is better than finding it dynamically. Preventing it by the way a system is defined is even better. Better yet, is not having to define (and build) it at all.”

Productivity increases with system size and complexity — the opposite of traditional approaches. This is attributed to formal and inherent support of reuse: “the larger a 001AXES system, the more it has the opportunity to capitalize on reuse.”

References

Section titled “References”

The paper contains 22 references including the 1976 HOS foundational paper, the Bolinger and Sears linguistic semantics work, the CMU/SEI feature-oriented domain analysis report, the DoD National Test Bed final report, and Hamilton’s prior publications.

Section titled “Related Documents”