AADL Concepts in SysMLv2: HAMR Library Documentation

Table of Contents

  1. Purpose and Scope
  2. SysMLv2 Primer for AADL Engineers
  3. The Core AADL Library (AADL.sysml)
  4. Data Modeling: Data_Model.sysml and Base_Types.sysml
  5. Property Sets
  6. HAMR Customizations
  7. Walkthrough: Isolette Example
  8. References

1. Purpose and Scope

This document explains how the Architecture Analysis and Design Language (AADL) concepts are represented in SysMLv2, a next-generation systems modeling language standardized by the Object Management Group (OMG). The representation is achieved through a set of SysMLv2 library packages that define part definitions, port definitions, connection definitions, enumerations, and attribute definitions that mirror AADL’s component categories, features, connections, and property sets.

The libraries are designed so that an application engineer can import the AADL library and model an AADL-style system architecture entirely in SysMLv2, using SysMLv2 inheritance (specialization) to create application-specific components that carry AADL semantics. A companion set of HAMR library files extends the core AADL libraries with additional properties and conventions used by the HAMR model-driven development tool for generating executable code from AADL/SysMLv2 models.

Who Should Read This

  • Software and systems engineers who know AADL and want to understand how to express AADL models in SysMLv2.
  • Engineers learning SysMLv2 who want a concrete, domain-specific example of how SysMLv2 libraries are built.
  • Users of HAMR who need to understand the SysMLv2 representation that HAMR consumes.

File Overview

File Role
AADL.sysml Core library: component categories, ports, connections
AADL_Project.sysml Shared enumeration types (dispatch protocols, scheduling, etc.)
Base_Types.sysml Primitive data types (Boolean, Integer, Float, String, etc.)
Data_Model.sysml Data modeling properties (size, representation)
Timing_Properties.sysml Time-related properties (period, deadline, execution time)
Thread_Properties.sysml Thread dispatch, priority, concurrency control
Communication_Properties.sysml Queue sizes, timing, transmission
Deployment_Properties.sysml Processor/memory binding, scheduling protocol
Memory_Properties.sysml Sizes, access rights, addresses
Programming_Properties.sysml Source language, source text references
Behavior_Properties.sysml Subprogram call protocols
HAMR.sysml HAMR-specific properties (implementation language, array sizing)
HAMR_AADL.sysml HAMR-extended component definitions
HAMR_Time_Units.sysml Convenience time units (ms, us, ns, ps)
CASE_Scheduling.sysml Domain-based scheduling properties

2. SysMLv2 Primer for AADL Engineers

SysMLv2 is a textual and graphical modeling language for systems engineering. Before diving into the AADL libraries, here are the key SysMLv2 concepts used throughout.

Packages

A package is a namespace that groups related definitions. Packages can be marked as library packages, meaning they provide reusable definitions intended to be imported by other models.

library package AADL {
  // definitions go here
}

An application model imports a library with the import keyword:

package MySystem {
  private import AADL::*;
  // now all definitions from AADL are available
}

(TBD: Further explain the difference between library packages and regular packages)

Part Definitions and Parts

A part def (part definition) defines a type of structural element — analogous to an AADL component type or component implementation. A part is an instance (usage) of that definition within a containing context — analogous to an AADL subcomponent declaration.

// Definition (like an AADL component type)
part def Thermostat :> Thread { ... }

// Usage (like an AADL subcomponent)
part thermostat : Thermostat;

Specialization (:>)

The :> operator declares that one definition specializes (inherits from) another. This is how AADL’s component hierarchy is built: all AADL component categories specialize a base Component, and application-specific components specialize the appropriate category.

// Thread specializes Component
part def Thread :> Component { ... }

// Application-level TempSensor specializes Thread
part def TempSensor :> Thread { ... }

All attributes, ports, and constraints from the parent definition are inherited by the child. The child can override inherited attributes using the :>> (redefinition) operator.

Attributes

An attribute declares a named property on a definition. Attributes have a type and can have default values. The :>> operator overrides an inherited attribute’s value.

part def Thread :> Component {
  attribute Period : Timing_Properties::Period;           // declare
  attribute Dispatch_Protocol : Thread_Properties::Dispatch_Protocol;
}

part def TempSensor :> Thread {
  attribute :>> Period = 1000 [ms];                       // override value
  attribute :>> Dispatch_Protocol = Periodic;             // override value
}

Port Definitions and Ports

A port def defines a type of interface point. A port is a usage of that definition on a component. Ports can carry directional flow items (in, out, inout).

port def DataPort :> Feature {
  inout part type : Data;
}

// Usage on a component
part def TempSensor :> Thread {
  port current_temp : DataPort { out :>> type : Temp; }
}

(TBD: Explain that HAMR doesn’t support inout and explain why.)

The out :>> type : Temp syntax means: “redefine the inherited type item to be outgoing and of type Temp.”

Connection Definitions and Connections

A connection def defines a type of link between parts or ports. A connection is a usage that binds specific source and target endpoints.

connection def PortConnection :> Connection { ... }

// Usage inside a system
connection tc : PortConnection connect
  temp_sensor.temp_changed to thermostat.temp_changed;

Enumeration Definitions

An enum def defines a set of named constants, directly analogous to AADL enumeration types.

enum def ComponentCategory {
  enum Abstract;
  enum Bus;
  enum Data;
  // ...
}

Allocation Definitions

An allocation def defines a mapping relationship between model elements — used in these libraries to represent AADL’s binding properties (e.g., binding a thread to a processor).

allocation def Actual_Processor_Binding {
  end part sw : AADL::Component;
  end part hw : AADL::Component;
}

Interface Definitions

An interface def defines a contract between two or more ports, including the flows and behaviors that occur across the connection. The AADL library uses this to model PortConnection with data flow semantics.

(TBD: Explain this in greater detail with more examples.)

3. The Core AADL Library (AADL.sysml)

The file AADL.sysml is the heart of the library. It defines:

  • An enumeration of all 14 AADL component categories
  • A part def for each category, carrying the relevant AADL properties as attributes
  • Port definitions for AADL features (DataPort, EventPort, EventDataPort, access features)
  • Connection definitions for AADL connection types

The library is declared as:

library package AADL {
  public import AADL_Project::*;
  public import Deployment_Properties::*;
  public import Thread_Properties::*;
  public import Timing_Properties::*;
  public import Communication_Properties::*;
  public import Memory_Properties::*;
  public import Programming_Properties::*;
  public import Data_Model::*;
  public import Behavior_Properties::*;
  // ...
}

The public import statements mean that when an application model writes import AADL::*, it automatically gets access to all property set enumerations and types — mirroring how AADL property sets are globally available.

3.1 Component Categories

AADL defines 14 component categories. The library represents them as an enumeration and as a hierarchy of part def definitions.

enum def ComponentCategory {
  enum Abstract;
  enum Bus;
  enum Data;
  enum Device;
  enum Memory;
  enum Process;
  enum Processor;
  enum System;
  enum Subprogram;
  enum SubprogramGroup;
  enum Thread;
  enum ThreadGroup;
  enum VirtualProcessor;
  enum VirtualBus;
}

abstract part def Component {
  attribute category : ComponentCategory;
}

Every concrete component category specializes Component and fixes its category attribute. This mirrors the AADL rule that every component belongs to exactly one category.

3.2 Software Components

AADL software components represent the executable parts of a system.

Thread

An AADL thread is a schedulable unit of concurrent execution. Threads have dispatch protocols (periodic, sporadic, etc.), timing properties (period, deadline, execution time), and memory-related properties. The SysMLv2 representation carries all of these as typed attributes:

part def Thread :> Component {
  attribute :>> category = ComponentCategory::Thread;

  attribute Dispatch_Protocol : Thread_Properties::Dispatch_Protocol;
  attribute Period : Timing_Properties::Period;
  attribute Deadline : Timing_Properties::Deadline;
  attribute Compute_Execution_Time : Timing_Properties::Compute_Execution_Time;
  attribute Priority : Thread_Properties::Priority;
  attribute Stack_Size : Memory_Properties::Stack_Size;
  attribute Source_Language : Programming_Properties::Source_Language;
  // ... many more timing and thread properties
}

An application model creates a specific thread by specializing this definition and overriding the desired properties:

part def TempSensor :> Thread {
  attribute :>> Period = 1000 [ms];
  attribute :>> Dispatch_Protocol = Periodic;

  port current_temp : DataPort { out :>> type : Temp; }
  out port temp_changed : EventPort;
}

Process

An AADL process represents a protected address space that contains threads. In the SysMLv2 library, a Process contains Thread parts as subcomponents and connections between them:

part def Process :> Component {
  attribute :>> category = ComponentCategory::Process;
  attribute Period : Timing_Properties::Period;
}

Data

An AADL data component represents a data type. It carries properties like Data_Size, Source_Language, and Access_Right:

part def Data :> Component {
  attribute :>> category = ComponentCategory::Data;

  attribute Data_Size : Memory_Properties::Data_Size;
  attribute Source_Language : Programming_Properties::Source_Language;
  attribute Source_Name : Programming_Properties::Source_Name;
  attribute value : Base::DataValue;
  // ...
}

Subprogram

An AADL subprogram represents a callable sequence of code (like a function). It carries execution time, memory size, and source language properties:

part def Subprogram :> Component {
  attribute :>> category = ComponentCategory::Subprogram;

  attribute Compute_Execution_Time : Timing_Properties::Compute_Execution_Time;
  attribute Code_Size : Memory_Properties::Code_Size;
  attribute Source_Language : Programming_Properties::Source_Language;
  // ...
}

(TBD: HAMR doesn’t support Subprogram components.)

3.3 Hardware and Execution Platform Components

AADL hardware components represent the physical execution platform.

Processor

An AADL processor is the hardware that executes threads. It has scheduling-related properties:

part def Processor :> Component {
  attribute :>> category = ComponentCategory::Processor;

  attribute Scheduling_Protocol : Deployment_Properties::Scheduling_Protocol;
  attribute Preemptive_Scheduler : Deployment_Properties::Preemptive_Scheduler;
  attribute Thread_Limit : Deployment_Properties::Thread_Limit;
  attribute Scheduler_Quantum : Timing_Properties::Scheduler_Quantum;
}

Memory

An AADL memory component represents storage (RAM, ROM, etc.):

part def Memory :> Component {
  attribute :>> category = ComponentCategory::Memory;

  attribute Memory_Size : Memory_Properties::Memory_Size;
  attribute Word_Size : Memory_Properties::Word_Size;
  attribute Base_Address : Memory_Properties::Base_Address;
  attribute Memory_Protocol : Deployment_Properties::Memory_Protocol
    default Deployment_Properties::Supported_Memory_Protocols::Read_Write;
}

Bus

An AADL bus represents a communication channel connecting hardware components:

part def Bus :> Component {
  attribute :>> category = ComponentCategory::Bus;

  attribute Transmission_Time : Communication_Properties::Transmission_Time;
  attribute Transmission_Type : Communication_Properties::Transmission_Type;
  attribute Period : Timing_Properties::Period;
}

Device

An AADL device represents an interface to the external environment (sensors, actuators). Devices can have dispatch protocols and execution times, making them similar to threads from a scheduling perspective:

part def Device :> Component {
  attribute :>> category = ComponentCategory::Device;

  attribute Compute_Execution_Time : Timing_Properties::Compute_Execution_Time;
  attribute Dispatch_Protocol : Thread_Properties::Dispatch_Protocol;
  attribute Period : Timing_Properties::Period;
}

VirtualProcessor and VirtualBus

These represent virtualized versions of their physical counterparts, used for modeling partitioned or virtualized execution platforms.

3.4 Composite Components

System

An AADL system is the top-level composite component that organizes all other components:

part def System :> Component {
  attribute :>> category = ComponentCategory::System;
  attribute Period : Timing_Properties::Period;
}

ThreadGroup

A thread group organizes threads within a process.

3.5 Ports and Features

AADL features (ports) are the interface points of components. The library defines a base Feature and concrete port types.

abstract port def Feature {
  attribute Transmission_Type : Communication_Properties::Transmission_Type;
}

DataPort

A data port carries typed data. It represents a continuous data stream — the most recent value is always available (no queuing). It is used for sampled communication:

port def DataPort :> Feature {
  inout part type : Data;
  attribute Base_Address : Memory_Properties::Base_Address;
}

EventDataPort

An event data port carries both an event notification and associated data. It supports queuing, so multiple values can be buffered:

port def EventDataPort :> Feature {
  inout part type : Data;
  attribute Queue_Size : Communication_Properties::Queue_Size default 1;
  attribute Base_Address : Memory_Properties::Base_Address;
}

EventPort

An event port carries only an event notification (no data payload). Like event data ports, it supports queuing:

port def EventPort :> Feature {
  attribute Queue_Size : Communication_Properties::Queue_Size default 1;
  attribute Base_Address : Memory_Properties::Base_Address;
}

Access Features

Access features represent shared access to components (data, buses, subprograms):

  • DataAccess — provides or requires access to a shared data component
  • BusAccess — provides or requires access to a bus
  • SubprogramAccess — provides or requires access to a callable subprogram
port def DataAccess :> Feature {
  inout ref type : Component;
  attribute Access_Right : Memory_Properties::Access_Right;
}

How Direction is Specified

In AADL, ports are declared as in, out, or in out. In SysMLv2, direction is specified at the port usage site by redefining the port’s flow item:

// An output data port of type Temp
port current_temp : DataPort { out :>> type : Temp; }

// An input event data port of type On_Off
port heat_control : EventDataPort { in :>> type : On_Off; }

3.6 Connections

AADL connections link ports of subcomponents. The library defines a Connection hierarchy.

abstract connection def Connection :> Connections::BinaryConnection {
  attribute Transmission_Type : Communication_Properties::Transmission_Type;
  attribute Timing : Communication_Properties::Timing;
}

PortConnection

The most commonly used connection type. It is defined as an interface def (rather than a connection def) to include flow semantics — data moves from source to target:

interface def PortConnection :> Connection, BinaryInterface {
  end port source : Feature;
  end port target : Feature;

  flow move {
    ref :>> payload : Data;
    end occurrence source : Feature :>> source = BinaryInterface::source;
    end occurrence target : Feature :>> target = BinaryInterface::target;

    action flow_action {
      accept d : Data via source;
      accept after 100.0 [s];
      send d via target;
    }
  }
}

Usage in an application model:

connection tc : PortConnection connect
  temp_sensor.temp_changed to thermostat.temp_changed;

Other Connection Types

  • FeatureConnection — a general-purpose connection between features
  • ParameterConnection — connects parameters of subprograms
  • AccessConnection — connects access features (data access, bus access)
  • FeatureGroupConnection — connects feature groups

4. Data Modeling: Data_Model.sysml and Base_Types.sysml

Data_Model.sysml

This small package defines the fundamental data modeling properties, corresponding to the AADL Data Modeling Annex:

package Data_Model {
  private import SI::*;

  attribute def Data_Size :> StorageCapacityUnit;

  enum def Number_Representation_enum {
    enum Signed;
    enum Unsigned;
  }

  enum def IEEE754_Precision {
    enum Simple;
    enum Double;
  }
}
  • Data_Size — specifies the storage size of a data type (in bytes or bits, using the SI units library)
  • Number_Representation_enum — whether an integer is Signed or Unsigned
  • IEEE754_Precision — whether a floating point value is Simple (32-bit) or Double (64-bit)

Base_Types.sysml

This package provides the standard primitive data types from AADL’s Data Modeling Annex, each specializing AADL::Data:

package Base_Types {
  private import AADL::*;
  private import Data_Model::*;

  part def Boolean :> Data {
    :> value : ScalarValues::Boolean;
  }

  part def Integer :> Data {
    :> value : ScalarValues::Integer;
    attribute Number_Representation : Number_Representation_enum
      = Number_Representation_enum::Signed;
  }

  part def Integer_8 :> Base_Types::Integer {
    :> Data_Size = 1 [byte];
  }

  part def Integer_16 :> Base_Types::Integer {
    :> Data_Size = 2 [byte];
  }

  part def Integer_32 :> Base_Types::Integer {
    :> Data_Size = 4 [byte];
  }

  part def Float :> Data {
    :> value : ScalarValues::Real;
  }

  part def Float_32 :> Float {
    :> Data_Size = 4 [byte];
    attribute IEEE754_Precisiion : IEEE754_Precision = IEEE754_Precision::Simple;
  }

  part def Float_64 :> Float {
    :> Data_Size = 48 [byte];
    attribute IEEE754_Precisiion : IEEE754_Precision = IEEE754_Precision::Double;
  }

  part def String :> Data {
    :> value : ScalarValues::String;
  }
}

The pattern is consistent: each base type specializes Data, binds the value attribute to the appropriate SysMLv2 scalar type, and sets size and representation properties. Application models can then use these as the data type carried by ports:

port current_temp : DataPort { out :>> type : Temp; }

where Temp itself specializes Data (see the Isolette walkthrough).

5. Property Sets

AADL organizes configurable properties into property sets — named collections of typed property definitions. Each property set is represented as a SysMLv2 package containing attribute def declarations. The property definitions use SysMLv2 multiple specialization to inherit from both AADL::Property (marking them as AADL properties) and a value type (e.g., Time, ScalarValues::Integer, an enumeration).

The general pattern is:

// In the property set package:
attribute def Period :> AADL::Property, Time;

// In a component definition:
attribute Period : Timing_Properties::Period;

// In an application model (overriding the value):
attribute :>> Period = 1000 [ms];

5.1 AADL_Project.sysml — Shared Enumerations and Types

The AADL_Project package defines shared enumeration types and measurement types that are referenced by multiple property sets. This corresponds to the AADL AADL_Project property set (SAE AS-5506D Appendix A8).

Key definitions include:

Dispatch Protocols — how threads are triggered:

enum def Supported_Dispatch_Protocols {
  enum Periodic;    // dispatched at regular time intervals
  enum Sporadic;    // dispatched by arriving events
  enum Aperiodic;   // dispatched by events, no minimum inter-arrival time
  enum Timed;       // dispatched by timeout
  enum Hybrid;      // combination of periodic and sporadic
  enum Background;  // runs when no other thread is ready
}

Scheduling Protocols — how the processor selects which thread to run:

enum def Supported_Scheduling_Protocols {
  enum Rate_Monotonic_Protocol;
  enum Earliest_Deadline_First_Protocol;
  enum POSIX_1003_Highest_Priority_First_Protocol;
  enum Round_Robin_Protocol;
  enum ARINC653;
  // ...
}

Concurrency Control Protocols — how shared data is protected:

enum def Supported_Concurrency_Control_Protocols {
  enum Priority_Inheritance;
  enum Priority_Ceiling;
  enum Spin_Lock;
  enum Semaphore;
  // ...
}

Time and Size Types — foundational measurement types:

attribute def Time :> ISQBase::DurationValue {
  attribute :>> num : ScalarValues::Integer;
}

attribute def Time_Range {
  attribute minimum : Time;
  attribute maximum : Time;
  attribute delta : Time;
}

attribute def Size :> StorageCapacityValue;

Convenient alias declarations allow using short names (e.g., Periodic instead of Supported_Dispatch_Protocols::Periodic).

5.2 Timing_Properties.sysml

Defines time-related properties from SAE AS-5506D Appendix A3. These control the temporal behavior of threads, processors, and other components.

Key properties:

Property Type Purpose
Period Time Dispatch interval for periodic threads
Deadline Time Latest acceptable completion time
Compute_Execution_Time Time_Range Min/max execution time per dispatch
Compute_Deadline Time Deadline for compute phase
First_Dispatch_Time Time Delay before first dispatch
Dispatch_Jitter Time Maximum variation in dispatch time
Scheduler_Quantum Time Time slice for round-robin scheduling
Frame_Period Time Period of a scheduling frame

All timing properties specialize both AADL::Property and the appropriate time type:

attribute def Period :> AADL::Property, Time;
attribute def Compute_Execution_Time :> AADL::Property, Time_Range;

5.3 Thread_Properties.sysml

Defines properties related to thread scheduling and dispatch from SAE AS-5506D Appendix A2.

Key properties:

Property Type Purpose
Dispatch_Protocol enum How the thread is triggered (Periodic, Sporadic, etc.)
Priority Integer Scheduling priority (higher = more urgent)
Criticality Integer Safety criticality level
Dequeue_Protocol enum How events are dequeued (OneItem, AllItems, MultipleItems)
Concurrency_Control_Protocol enum How shared data is protected
POSIX_Scheduling_Policy enum POSIX scheduling class
Runtime_Protection Boolean Whether address space isolation is enforced
Synchronized_Component Boolean Whether the component is synchronized

5.4 Communication_Properties.sysml

Defines properties governing data exchange between components, from SAE AS-5506D Appendix A4.

attribute def Queue_Size :> AADL::Property, ScalarValues::Integer;

enum def Supported_Timing_Protocols {
  enum Sampled;     // reader samples latest value at dispatch
  enum Immediate;   // data transfer occurs at sender's dispatch
  enum Delayed;     // data transfer occurs at sender's deadline
}
attribute def Timing :> AADL::Property, Supported_Timing_Protocols;

enum def Supported_Transmission_Types {
  enum Push;   // sender initiates transfer
  enum Pull;   // receiver initiates transfer
}
attribute def Transmission_Type :> AADL::Property, Supported_Transmission_Types;
  • Queue_Size — depth of the event/event-data port queue (default is 1)
  • Timing — Sampled, Immediate, or Delayed communication semantics
  • Latency and Actual_Latency — expected and measured end-to-end latency as Time_Range

5.5 Deployment_Properties.sysml

Defines properties for binding software to hardware, from SAE AS-5506D Appendix A1. This package uses SysMLv2 allocation definitions to represent AADL bindings:

allocation def Actual_Processor_Binding {
  end part sw : AADL::Component;
  end part hw : AADL::Component;
}

allocation def Actual_Memory_Binding {
  end part sw : AADL::Component;
  end part hw : AADL::Component;
}

allocation def Actual_Connection_Binding {
  end part cnx : AADL::Component;
  end part bus : AADL::Component;
}

These allocations model which processor executes a given thread, which memory stores a given process, and which bus carries a given connection.

Additional properties include:

  • Scheduling_Protocol — which scheduling algorithm the processor uses
  • Preemptive_Scheduler — whether the scheduler can preempt running threads
  • Thread_Limit — maximum number of threads a processor can host

5.6 Memory_Properties.sysml

Defines size and access properties for memory and data, from SAE AS-5506D Appendix A5.

Property Type Purpose
Data_Size Size Size of a data component
Code_Size Size Size of compiled code
Stack_Size Size Thread stack allocation
Heap_Size Size Dynamic memory allocation
Memory_Size Size Total capacity of a memory component
Word_Size Size Word width (default 8 bits)
Base_Address Integer Starting address in memory
Access_Right enum Read_Only, Write_Only, Read_Write, By_Method

5.7 Programming_Properties.sysml

Defines properties relating components to source code, from SAE AS-5506D Appendix A6.

attribute def Source_Language :> AADL::Property, Supported_Source_Languages;
attribute def Source_Name :> AADL::Property, ScalarValues::String;
attribute def Source_Text :> AADL::Property, ScalarValues::String;
attribute def Type_Source_Name :> AADL::Property, ScalarValues::String;
  • Source_Language — the programming language (Ada95, C, Java, etc.)
  • Source_Name — fully qualified name of the implementing code element
  • Source_Text — path to source files
  • Type_Source_Name — name of the data type in the source language

5.8 Behavior_Properties.sysml

Defines properties from the AADL Behavior Annex (SAE AS-5506/3 Annex D):

package Behavior_Properties {
  enum def Supported_Subprogram_Call_Protocols {
    enum HSER;   // High-Speed Event Response
    enum LSER;   // Low-Speed Event Response
    enum ASER;   // Asynchronous Event Response
  }
  attribute def Subprogram_Call_Protocol :> Supported_Subprogram_Call_Protocols;
}

6. HAMR Customizations

The HAMR tool extends the base AADL libraries with additional definitions tailored for code generation. These are found in the hamr.aadl.library folder.

HAMR.sysml — HAMR-Specific Properties

library package HAMR {
  public import HAMR_Time_Units::*;
  public import HAMR_AADL::*;
  public import AADL::*;

  attribute def Array_Size_Kind :> AADL::Property, Array_Size_Kinds;

  enum def Array_Size_Kinds {
    enum Fixed;      // exact size, statically allocated
    enum Bound;      // maximum size, may be partially filled
    enum Unbounded;  // no static limit, runtime checked
  }

  attribute def Implementation_Language :> AADL::Property, Implementation_Languages;

  enum def Implementation_Languages {
    enum Slang;   // Sireum Slang (Scala subset)
    enum C;
    enum Rust;
  }
}
  • Array_Size_Kind — controls how HAMR generates array types: Fixed means a compile-time constant size, Bound means a maximum capacity with a runtime length, and Unbounded means dynamic allocation.
  • Implementation_Language — specifies the target language for code generation (Slang, C, or Rust).

The HAMR package re-exports all of AADL, HAMR_AADL, and HAMR_Time_Units, so application models only need import HAMR::* to access everything.

HAMR_AADL.sysml — Extended Component Definitions

HAMR extends certain AADL component definitions with additional properties:

package HAMR_AADL {
  private import AADL::*;

  part def Processor :> AADL::Processor {
    attribute Frame_Period : Timing_Properties::Frame_Period;
    attribute Clock_Period : Timing_Properties::Clock_Period;
  }

  part def Process :> AADL::Process {
    attribute Domain : CASE_Scheduling::Domain;
  }

  part def Thread :> AADL::Thread {
    attribute Implementation_Language : HAMR::Implementation_Language;
  }
}
  • HAMR_AADL::Processor adds Frame_Period and Clock_Period (used for static scheduling frame configuration).
  • HAMR_AADL::Process adds Domain (the scheduling domain ID for CASE/seL4-based partitioning).
  • HAMR_AADL::Thread adds Implementation_Language (the target language for the generated thread code).

When an application model imports HAMR::*, the HAMR-extended definitions shadow the base AADL ones, so Thread refers to HAMR_AADL::Thread (which inherits all of AADL::Thread’s properties plus Implementation_Language).

HAMR_Time_Units.sysml — Convenience Time Units

AADL models frequently use milliseconds, microseconds, and nanoseconds, but the SysMLv2 SI library only pre-defines seconds. This package adds the common subunits:

package HAMR_Time_Units {
  public import SI::*;

  attribute ps : DurationUnit = s * pico;   // picoseconds
  attribute ms : DurationUnit = s * milli;  // milliseconds
  attribute us : DurationUnit = s * micro;  // microseconds
  attribute ns : DurationUnit = s * nano;   // nanoseconds
}

This allows writing 1000 [ms] or 500 [us] in attribute assignments.

CASE_Scheduling.sysml — Domain Scheduling

package CASE_Scheduling {
  attribute def Domain :> AADL::Property, ScalarValues::Integer;
  attribute def Max_Domain :> AADL::Property, ScalarValues::Integer;
}
  • Domain — the numeric scheduling domain ID assigned to a process or thread. This is used in CASE (Cyber Assured Systems Engineering) and seL4-based platforms where threads are partitioned into time-isolated domains.
  • Max_Domain — the maximum domain ID supported by the platform.

7. Walkthrough: Isolette Example

The simple-isolette/Isolette.sysml file demonstrates how an application model uses the AADL libraries to define a complete system. The Isolette is a standard example system — a baby incubator that maintains a set temperature range.

Package and Import

//@ HAMR: --platform JVM --output-dir . --slang-output-dir . --package-name cis771
package Isolette {
    private import HAMR::*;
    // ...
}

The comment line //@ HAMR: is a HAMR directive that tells the code generator which platform and output settings to use. The single import HAMR::* brings in all AADL component definitions, port types, property enumerations, and time units.

Data Types

The model defines its application-specific data types by specializing the AADL Data component (via Struct, a convention for record/struct data types):

part def Temp :> Struct {
    degrees : Base_Types::Integer;
}

part def Set_Points :> Struct {
    lower : Temp;
    upper : Temp;
}

enum def On_Off {
    enum On;
    enum Off;
}
  • Temp — a temperature reading with an integer degrees field
  • Set_Points — a pair of temperatures defining the desired range
  • On_Off — an enumeration for the heater control signal

Thread Definitions

The model defines reusable thread templates and concrete thread components:

// Reusable template: a 1-second periodic thread
part def PeriodicThread1s :> Thread {
    attribute :>> Period = 1 [s];
    attribute :>> Dispatch_Protocol = Periodic;
}

// Reusable template: a sporadic thread
part def SporadicThread :> Thread {
    attribute :>> Dispatch_Protocol = Sporadic;
}

These intermediate definitions show how SysMLv2 specialization can be layered — PeriodicThread1s specializes Thread (which comes from HAMR_AADL::Thread, which specializes AADL::Thread), and concrete threads specialize these templates:

part def TempSensor :> Thread {
    port current_temp : DataPort { out :>> type : Temp; }
    out port temp_changed : EventPort;

    attribute :>> Period = 1000 [ms];
    attribute :>> Dispatch_Protocol = Periodic;
}

part def OperatorInterface :> PeriodicThread1s {
    port desired_temp : EventDataPort { out :>> type : Set_Points; }
}

part def HeatSource :> SporadicThread {
    port heat_control : EventDataPort { in :>> type : On_Off; }
}

part def Thermostat :> SporadicThread {
    port current_temp : DataPort { in :>> type : Temp; }
    in port temp_changed : EventPort;
    port desired_temp : EventDataPort { in :>> type : Set_Points; }
    port heat_control : EventDataPort { out :>> type : On_Off; }
}

Each thread declares its ports with direction and data type, demonstrating the SysMLv2 pattern of overriding the type attribute in the port definition.

Process Definitions

Threads are grouped into processes (protected address spaces):

part def OperatorInterface_Process :> Process {
    part operator_interface : OperatorInterface;

    port desired_temp : EventDataPort { out :>> type : Set_Points; }
    connection dt : PortConnection connect
        operator_interface.desired_temp to desired_temp;
}

part def Control_Process :> Process {
    part temp_sensor : TempSensor;
    part thermostat : Thermostat;
    part heat_source : HeatSource;

    port desired_temp : EventDataPort { in :>> type : Set_Points; }

    connection tc : PortConnection connect
        temp_sensor.temp_changed to thermostat.temp_changed;
    connection ct : PortConnection connect
        temp_sensor.current_temp to thermostat.current_temp;
    connection hc : PortConnection connect
        thermostat.heat_control to heat_source.heat_control;
    connection dt : PortConnection connect
        desired_temp to thermostat.desired_temp;
}

Key points:

  • Subcomponents are declared as part usages (e.g., part thermostat : Thermostat)
  • Process-level ports allow data to cross process boundaries (e.g., desired_temp on Control_Process)
  • Connections use PortConnection connect ... to ... syntax to wire subcomponent ports together
  • A connection from a process-level port to a subcomponent port (e.g., desired_temp to thermostat.desired_temp) represents a port delegation

System Definition

The top-level system composes the processes:

part def Isolette_System :> System {
    part operator_interface_process : OperatorInterface_Process;
    part control_process : Control_Process;

    connection dt : PortConnection connect
        operator_interface_process.desired_temp to control_process.desired_temp;
}

This system contains two processes and a single cross-process connection carrying the Set_Points data from the operator interface to the control logic.

Architecture Summary

Isolette_System (System)
├── operator_interface_process (Process)
│   └── operator_interface (PeriodicThread1s, 1s)
│       └── out desired_temp : EventDataPort [Set_Points]
│
└── control_process (Process)
    ├── temp_sensor (Thread, Periodic, 1000ms)
    │   ├── out current_temp : DataPort [Temp]
    │   └── out temp_changed : EventPort
    │
    ├── thermostat (SporadicThread)
    │   ├── in current_temp : DataPort [Temp]
    │   ├── in temp_changed : EventPort
    │   ├── in desired_temp : EventDataPort [Set_Points]
    │   └── out heat_control : EventDataPort [On_Off]
    │
    └── heat_source (SporadicThread)
        └── in heat_control : EventDataPort [On_Off]

Connections:

  • operator_interface.desired_temp → thermostat.desired_temp (across process boundary)
  • temp_sensor.temp_changed → thermostat.temp_changed
  • temp_sensor.current_temp → thermostat.current_temp
  • thermostat.heat_control → heat_source.heat_control

8. References

AADL

SysMLv2

HAMR

Presentations and Talks

  • Representing AADL in SysMLv2 — Presentations on the AADL-to-SysMLv2 mapping approach are periodically given at SAE AADL meetings and OMG SysML workshops. Check the AADL wiki events page for recordings and slides.
  • CASE (Cyber Assured Systems Engineering) — DARPA program that uses AADL/HAMR for high-assurance system development: https://loonwerks.com/projects/case.html