MetaH Language and Tools

MetaH Language

At first glance, MetaH appears similar to many existing structured design or object-oriented design notations. The graphical representation of MetaH allows objects to be placed on a screen and connected together, where each object may be defined as another collection of connected component objects in a hierarchical manner. However, MetaH has a rich set of object types that have well-defined semantics, precise enough to perform real-time schedulability or other analyses and to automatically create a load image from the various source modules named in a specification.

MetaH allows a specification of system components and connections, and attributes of those components and connections that are relevant to real-time, fault-tolerant, secure partitioning, and multi-processor aspects of an application. The kinds of objects in a MetaH specification can be divided into lower-level objects that describe source code modules (e.g. subprograms, packages) or hardware elements (e.g. memories, processors); and higher-level objects that specify how previously declared objects may be combined to form new objects (modes, macros, systems, applications).

The MetaH language has both a textual and a graphical syntax, and the tools allow a specification to be viewed and edited interchangeably in either format. The figure below illustrates the general structure of MetaH specifications using the graphical syntax. This MetaH graphical specification can be automatically translated to a MetaH textual version or vice versa.

Objects in a MetaH specification have separate interface and implementation definitions, where multiple alternative implementations can be defined for the same interface. The left part of the figure above shows an interface for a macro named M, while the right part shows one implementation for this interface. An interface specification may contain shareable monitors and packages; and/or source objects called ports and events (e.g. macro M has two ports in its interface). The objects in an interface appear in every implementation for that interface (e.g. the ports m_in and m_out in the right-hand diagram). An implementation may contain additional component objects and connections between those components (e.g. P1 and P2 are components within macro implementation M.EXAMPLE). The icons shown for processes P1 and P2 similarly represent interfaces for process objects, and specifications for internal implementations for these objects exist as diagrams that can also be examined in the graphical editing tool.

A process (e.g. P1, P2) is the fundamental unit of scheduling, allocation to hardware processors, and fault and security containment. Both periodic and aperiodic processes are supported. While a periodic process is active it is automatically and repeatedly dispatched with some periodicity that is specified as an attribute of that process. An aperiodic process is dispatched each time a connected event occurs. All dispatched but not yet completed processes are scheduled according to a preemptive fixed priority discipline.

Process implementations can be hierarchically decomposed into package and subprogram components to the level of detail desired. A variety of process attributes relating to real-time scheduling, security, fault behavior, and multi-processor allocation can be specified. The following figure shows how an attribute window is used to examine and set the attributes of an object in a MetaH specification.

A process interface may (among other things) identify input and output ports, which correspond to input and output buffer variables within the source code. Process ports are connected together to indicate communication that is to occur between processes at run-time (e.g.between P1 and P2). Ports are strongly typed using the type system of the underlying source language, and port-to-port connections are type checked. The icon labeled PORT_TYPES lists some port types that have been defined in this specification. Port-to-port connections cause periodic assignments to occur between buffer variables, where there is a way in a MetaH specification to associate buffer variables in the source code with ports declared in a MetaH object interface. These assignments must be scheduled to occur in a way that takes into account the periodicities and deadlines of the communicating processes. This is done in a way that provides correct state update semantics (e.g. the feed-back connections in the diagram on the right behave as needed to properly implement feed-back control algorithms).

Sharing of code and data in the form of shared packages is supported. Packages that appear in the interfaces of two different processes are made to correspond to the same physical copy using an equivalence connection in the MetaH specification. If synchronized access is desired, then the shared package can be designated as a monitor. This makes a real-time semaphore available in the final generated application that can be used to synchronize access to the shared package.

A macro allows a connected collection of objects to be treated as a single object for the purposes of building a complex, hierarchical architecture specification. Instances of the macro M specified in the figure above can be used as a component in another specification diagram, for example.

The syntax used to specify a mode is very similar to that used to specify a macro, but there is an important semantic distinction. Where multiple modes appear in a design diagram, only one of them is in effect or active at the same time. Event connections between modes define a state transition diagram, and events that occur at run-time can cause the system to dynamically transition between different configurations. A mode transition can have the effect of stopping some processes, starting some processes, and/or changing the pattern of port-to-port or event connections.

An important aspect of the MetaH language is that it allows the hardware as well as the software architecture to be specified. Multi-processor systems can be composed from processors, memories and channels (hardware that enables message passing between processors). Attributes can be used to control the allocation of processes to processors, shared packages to memories, and port-to-port message connections to channels. Here is a MetaH specification of a simple dual-processor system, for example.

Hardware objects may have input and output ports and events, just like software objects. Processors may also provide monitors, which allows hardware-dependent subprograms to be made available in a reasonably general way. The symmetry between the way software modules interface with each other and with the hardware makes it much easier to develop target-independent and portable applications.

MetaH Tools

The figure below shows the existing MetaH tools. MetaH architecture specifications can be developed using either the graphical or the textual syntax, where the tools can translate one form into the other. In addition to the editing tools, there are tools to perform various checks and analyses and tools to automatically build load images.

The workspace that ties the tools together is currently not persistent, and all the analysis and code assembly tools are currently a part of the same load image and are executed in sequence when an architecture specification is processed (but can be individually suppressed using command-line options).

Hardware/Software Binding

With a multi-processor architecture specification, allocations or bindings must be made of processes to processors, shared packages to shared memories, and port-to-port messages to inter-processor channels. The hardware/software binder assist in making reasonable choices for these bindings.

A MetaH specification may contain an explicit binding for a software object. It may also specify a set of acceptable bindings, or a type of hardware component to which a software object may be bound. Where user specifications do not uniquely determine a binding, the software/hardware binder will use a heuristic optimizing algorithm to bind the remaining software objects.

Real-Time Schedulability Analysis

The schedulability analysis tool builds and solves a real-time schedulability model for the specified architecture. A schedulability analysis determines whether every processor and every inter-processor channel will be feasibly scheduled in every mode of operation. The schedulability model includes all executive and kernel overhead times.

In addition to showing whether the schedule is feasible, the report includes sensitivity analysis information that allows the impact of changes to be assessed. This is particularly useful in managing the development process and in performing multi-disciplinary design trade-offs that involve both the GN&C and the computer system engineers.

Reliability Analysis

MetaH allows you to specify error models that describe the kinds of faults that may occur (e.g. permanent, transient), the error states that objects may be in (e.g. error_free, recoverable, failed), and collections of state machines that describe how the error states of an object might change as fault events and error propagations occur. Objects in a specification are then annotated to indicate which error model to use, what the fault arrival and error propagation rates are, etc. Concensus expressions (boolean-valued expressions over the error states of objects, e.g. 2 ormore (A, B, C)) are used to model concensus protocols, control error propagation, and define the configurations in which a fault-tolerant system is still operable. A specification for a three-computer system that uses error masking illustrates these features.

The reliability analysis tool first builds a stochastic concurrent process reliability model, and from this generates a Markov chain model that may be solved by a number of existing tools (e.g. SURE).

This tool is still a research prototype.

Safety/Security Analysis

The current MetaH system provides three security mechanisms at run-time. First, data security is provided by allocating each application process its own protected virtual address space. Processes can access common memory only if an equivalence connection authorizes this in the MetaH specification. Second, control security is provided using capability lists generated for each process. A process can only change to a specific mode, dispatch a specific aperiodic process, lock a specific monitor semaphore, or invoke a specific kernel service if this appears in the MetaH specification. Third, timing security is provided in the form of enforced execution time limits on process initialization, process computation, and monitor locking times; or by specifying relative process scheduling criticalities.

MetaH allows you to specify a safety level for each object, a value that ranges from A0 (highest safety level) to Z9 (lowest safety level). The safety/security analysis tool checks to see that nothing in a specification allows a less-safe object to affect the proper operation of a more-safe object. Examples of the kinds of checks performed are checks to insure that data does not flow from a less-safe to a more-safe object (unless this has been explicitly approved), checks to insure that the execution of a less-safe object cannot impact the scheduling of a more-safe object.

This tool is still a research prototype.

Automatic Code Assembly/Composition

Application source modules identified in the MetaH specification are assembled into processes, together with an automatically generated KERNEL service call package that provides a target-independent interface to kernel services. Each application process becomes a program that is compiled and prelinked into its own protected virtual address space. The current tool accommodates simple versioning techniques ("make" facilities) so that repeated MetaH compiles do not force source recompiles unless an application source module has been changed or added (a few hundred lines of MetaH can easily specify applications having many dozens of source modules and many tens of thousands of lines of source code).

The executive generator tool produces an application-specific supervisor or executive that performs the process dispatching, message passing, access synchronization, capabilities checking, and event vectoring specified in the MetaH specification. Process scheduling is based on rate monotonic scheduling theory, where the tool automatically assigns priorities, transforms periods as necessary, and generates code to manage process dispatching and continuation. Inter-process and inter-processor communication code is statically scheduled and executed as part of the generated dispatcher. Event vectoring, and the starting and stopping of processes at mode changes, are also controlled by generated code. All this must be done in a way that is mode-dependent, since scheduling and communication varies from mode to mode.

The generated executive makes use of a standard interface to certain low-level scheduling primitives typically provided by a microkernel and has been designed to be reasonably easy to retarget to different platforms. Our current implementation uses the Tartan Ada multi-application run-time as the underlying microkernel. An application builder has been developed for the Tartan Ada toolset targeted to an i80960MC processor. This build tool automatically performs the compilations and links needed to make a load image for this type of processor using this toolset.

A retarget of MetaH to GNAT/Solaris is nearing completion. This will provide a low-cost way of producing non-real-time simulations for execution and debugging on a development workstation.