The nature of embedded system software has changed fundamentally. In avionics, for example, yesterday's embedded software was a federation of relatively simple control loops; but today's embedded software systems are the glue which integrate the entire platform, presenting high level situation awareness to the pilot. Soon there will be UCAV's in which software will play the role of the pilot, blurring the traditional boundary between pilot and platform and requiring wholly new forms of integration. Current techniques for producing these systems are inadequate. The traditional approaches of entangling concerns in order to meet space and time constraints has led to software systems inconsistent with the goal of evolution. Model-based methods offer a better approach: Programmers have a variety of models in their heads; these models structure the problem into functional domains, into levels of abstraction and into techniques for managing cross-cutting concerns. They use these models to translate high level goals into code. The power is in the models. Instead of throwing them away once code is written, they should be represented explicitly and used to synthesize efficient reactive code. They should be available in the runtime system to faciliate integration and robustness. The software must present a model-based view of its execution in terms of goals, strategies, plans, state-variables, and invariants. These should be monitored at runtime and the failure to achieve expected results should trigger diagnosis, reconfiguration and recovery.

Approach:

At the lowest level, reactive controllers iterate through the following three steps:

1. Mode Identification which attempts to characterize the current state of the system;
2. Mode Selection, which is invoked if the current state is faulty, and which identifies a working mode of the system that is reachable from the current state;
3. Reactive Planning which identifies a set of steps capable of achieving the goals posted by Mode Selection and by external components.

Thus the software must make deductions at reactive speeds. But, the computational power available to embedded systems is becoming abundant, allowing model-based deduction to be embedded even in the lowest level, reactive components of the control systems.

Embedded software should be developed against the backdrop of model-based frameworks, each tailored to a single (or a small set of) issues. Some frameworks deal with cross-cutting issues such as fault tolerance; others deal with particular components and functional layers of a complex system (e.g. control of an observational asset in a UCAV). A framework, as we use the term, includes a set of properties with which the framework is concerned, a formal ontology of the domain, an axiomatization of the core domain theory, analytic techniques tailored to these properties and their domain theory, a runtime infrastructure providing a rich set of services, and an embedded language for describing how a specific application couples into the framework.

A framework thus reifies a model in code, API, and in the constraints and guarantees the model provides. Each framework exposes its own goals, plans, state-variables and invariants in terms of an embedded language which captures the terms and concepts used by application domain experts. Each framework also expresses its dependencies on other frameworks in the same language. These are then used to synthesize the code which integrates the ensemble of frameworks into a unified, reactive system.

Our Quad Chart