FOR THE COMMANDER

Abstract : This report recommends three distinct regulatory strategies for addressing difficulties the Department of Defense (DoD) has been experiencing with respect to legal issues related to software acquisitions. First, the report reiterates the Software Licensing Project's earlier recommendation that the DoD adopt the proposed Federal Acquisition Regulation (FAR) data rights provisions instead of the proposed revisions to the DoD supplement to the FAR (DoD FAR SUPP). Secondly, in the event that the Defense Department chooses to adopt a data rights procurement policy different from that found in the data rights provisions of the proposed FAR, this report recommends that the DoD adopt a separate Rights in Software clause for software acquisitions, rather than continuing the present practice of handling software procurements under the Rights in Technical Data clause. Reasons in support of a separate software acquisition policy, as well as a beginning model Rights in Software clause are offered. Finally, in the event that the DoD elects to retain the procurement format presently found in the DoD FAR SUPP provisions governing software and technical data acquisitions, this report offers several concrete recommendations for changes to those regulations which should result in a procurement policy which more effectively meets the mission needs of the Defense Department.

The application developer is responsible for prescribing a way to manage all of these resources. We call this prescription a task-level application description. It describes the tasks to be executed, the assignment of processes to processors, the data paths between the processors, and the intermediate queues required to store the data as it moves from source to destination processes. A task-level description language is a notation in which to write these application descriptions.
We are using the term "description language" rather than "programming language" to emphasize that a task-level application description is not translated into object code in some kind of executable "machine language." Rather, it is to be understood as a description of the structure and behavior of a logical machine, that will be synthesized into resource allocation and scheduling directives. These directives are to be interpreted by a combination of software, firmware, and hardware in a heterogeneous machine.
We have an initial design of such a description language [1], a compiler for it, and a simulator that takes task descriptions as input. A task description (see Figure 1) contains information about four aspects of a task: (1) its interlace to other tasks (ports) and to the scheduler (signals); (2) its functional and timing behavior, (3) its attributes, and (4) its internal structure, thereby allowing for hierarchical task descriptions. Reference [1] contains a more complete explanation of these and other features of the language. In this paper we focus on only one aspect: the information appearing in the behavior part of a task description.

Contributions
Formal specifications have been used successfully for specifying the functional behavior of software systems, e.g., individual program modules and abstract data types. These specifications have traditionally been used to verify a program's correctness ("is the right answer computed?"). Often, however, one is interested in not only the functional correctness of a system but also other properties, such as reliability, performance, security, and real-time behavior. Less work has focused on formally specifying these other properties of software systems, let alone their interactions with each other.
To our knowledge no work has addressed the formal integration of the formal specification of functional and timing behavior of software. The main contribution of this paper is exactly this integration of functional and timing specifications as embodied in our task description language.
task task-name ports port-declarations signals signal-declarations behavior requires predicate ensures predicate timing timing expression attributes attribute-value-pairs structure process-declarations queue-declarations reconfiguration-statements end task-name -Usad for coaoninication batwaan a procass and a quaua -Usad for coominication batwaan a uaar procass and tha schadular -A description of tha functional and timing bahavior of tha task -Additional propartias of tha task A procass-quaua graph describing tha intamal structure of a task

Figure 1: A Template for Task Descriptions
We combine two separate formalisms: an axiomatic specification language, Larch [11,12], used to specify functional behavior, and an event expression language used to specify timing behavior. Both are mapped to the same underlying logic, typed first-order predicate logic, so that their combination has a formal semantics. Two significant aspects of our work are as follows: • Since the formal semantics is relatively simple (first-order logic), not only can people easily understand our specifications but the specifications themselves can easily be subject to machine analysis. • We build upon previous well defined and isolated pieces of research and combine them in a meaningful way. Their combination is applied in a context (heterogeneous machines) that itself is of growing interest to those involved in parallel architectures and languages.

Introduction to Larch
Before we describe the functional and timing specifications of a task, we give a brief introduction to Larch uses a two-tiered approach to specifying program modules: a trait defines state-independent properties, and an interface specification defines state-dependent properties of a program. A trait is written in the Larch Shared Language (LSL), and it provides the assertion language used to express and define the meaning of the predicates of an interface specification.

For a program module, such as a procedure, a Larch interface specification is written in a Larch Interface
Language (LIL) and contains predicates about the states before and after the execution of the procedure.
The Larch Interface Language to be used is specific to the programming language in which the procedure is written (e.g., C, CommonLisp, Ada, etc.). For this paper we will use a relatively simple interface language, such as would be defined for an Algol-like language.
, ^ KM Tha reader is encouraged to consult the appropnate references .n the iWe are keeping this introduction to Larch very short The reader .s enc g bibliography.

Syntax and Meaning
The timing information describes the behavior of the task in terms of the operations that it performs on the queues attached to its input and output ports; this is the behavior of the task seen from the outside. 1. the number of times the task is to be executed: "repeat integer => expression," or 2. during what time interval the task is allowed to start: "during timewindow => expression," or 3. the earliest allowable start time: "after timevalue => expression" or 4. the latest allowable start time "before timevalue => expression" or 5. a predicate on the state of the input queues or the current time which must be true before the task is allowed to start: "when predicate => expression." In our examples, we will often drop the name of the queue operation and use just the name of the port (i.e., "inl" instead of "inl.Dequeue"). Since this paper introduces only two queue operations: Enqueue and Dequeue, and given that the former applies only to input queues and the other applies only to output queues, no confusion should occur as to which operation is implied.

Example
Consider a matrix multiplication task (Figure 4) that takes input matrices from two queues and outputs the result matrix on an output queue. The timing clause states that the task does not start executing until both input queues contain data. Once that condition is satisfied, the task will remove its input data from both input queues concurrently (the Dequeue operations), will operate on the data for between 10 and 15 seconds (this "computation" time is lumped together under the delay operation), and finally will enqueue some output in the output queue. Notice another use of LSL in our specifications: the when condition places a constraint on the state of the queues (not on the state of the data in the queues). We use the trait from Section 3 to define the assertion language for predicates in a when guard.

Meaning
The start of an operation ("action" in RTL's terminology).

The end of an operation.
The time of the i th occurrence of event E, where events in our context are the start of an operation or the end of an operation. @ is an occurrence function that captures the notion of real-time. The interval of time during which the predicate P holds. P holds before or at t1, from t1 to t2, and at or after t2. If t1 and t2 are identical, then P holds at an interval around tt. For brevity, we will use P(t) when t1 =t2 (i.e., "P holds around time t").

Assigning Meaning to Timing Specifications
In this section we describe the meaning of our timing specifications in terms of RTL logic. In the following discussion, we assume E, E1, and E2 are arbitrary timing expressions; A, Al, and A2 are operations; t1 and t2 are times (absolute or relative); a1 and a2 are absolute times; r1 and r2 are relative times; and W is a predicate of a when guard.
To simplify the exposition, we introduce a simple rewite rule: Any timing expression of the form "repeat n => E" can be rewritten as a sequence of n occurrences of the unguarded expression E ("E E E ... E").
Thus, the only guards we need to consider are before, after, during, and when.
We also introduce the following axioms: where J and K are the number of output and input queues, respectively.

For any queue operation
We assign a meaning to timing expressions by introducing a function, (Table 1 .

Mj : Timing Expression -H> Boolean.
We use an auxiliary function, op (Table 1.

op: Timing Expression -> Operation.
op is needed because "start time" and "end time" are meaningful only for queue operations.
As an example of how to interpret the formalism intuitively, consider the entries for the during guard in Table 1.a. They specify a time window during which the operation is allowed to start. The first value is the earliest start time allowed and must be an absolute time value. The second value is the latest start time allowed and can be an absolute time value or a time value relative to the former. The meaning of the guarded expression is the conjunction of the meaning of the expression proper and a predicate stating the restriction on starting times.

Req E V i [ Req(@(Top(E), i)) A M,(E) ] Ens E V i [ Ens(@(iop(E), i)) A M^E) ]
The function Mf is precisely the link between the functional and timing specifications. This link is characterizable purely in terms of first-order logic. To further illustrate the richness of our specification language and to show the benefits of cleanly separating the functional from the timing information, we write three alternative descriptions for a task built into our library. This task, deal, has one input port and a number of output ports. Data dequeued from the input port is enqueued to one of the output ports, but this can be implemented in a number of ways as illustrated in Figure 6 Hest(ini))),

Examples
The first example (Figure 6.a) states that we alternate the dequeueing of input and enqueueing of output and ensures that first (second) output queue will see the first (second) item removed from the input queue. The second example (Figure 6.b) states that we dequeue all input before the output operations start, which themselves take place concurrently. It allows for the first dequeued data item to be enqueued on either of the output queues, but ensures that the second dequeued item will not be enqueued to the same as the first. The third example (Figure 6.c) states that input data are dequeued and grouped in pairs before enqueueing them into the output ports. The first pair is enqueued to the first output queue; the second pair, to the second. where first-order predicate logic pre-and post-conditions are used for the specification of each operation of the type. The algebraic approach, which defines data types to be heterogeneous algebras [2], uses axioms to specify properties of programs and abstract data types, but the axioms are restricted to equations.
Much work has been done on algebraic specifications for abstract data types Specification and verification of timing requirements for real-time systems include recent work by Dasarthy [5], and by Lee, Gehlot, and Zwarico [17,29]. This work as well as that by Jahanian and Mok, whose real-time logic we borrow, all focus on timing properties and not on functional behavior. Either states are left uninterpreted or predicates on states are simplistic, e.g., boolean modes as in Jahanian and Mok's work. In contrast, since we have a formal means of specifying the functional behavior of tasks and the data on which they operate, we have a more expressive specification language with a richer semantics.

Summary
Our approach to specifying the functional and timing behavior of real-time applications for a heterogeneous machine has the following characteristics: • It takes advantage of two well defined, though isolated, pieces of previous work.
• There is a clean separation of concerns between the two specifications.
• The semantics of both specifications as well as their combination are simple.
In our language design, we strove to separate the functional specification from the timing specification so that a task's functionality could be understood independent of its timing behavior. This separation of concerns gives us the usual advantages of modularity. Different timing specifications can be attached to the same functional specification. Task implementors can focus on satisfying functionality first, timing second. Task validation can be performed separately. For example, one could use formal verification for functionality and simulation for timing.
Since the semantics can be given in terms of first-order predicate logic, our specifications are amenable to machine manipulation and analysis. The algebraic style of Larch traits can be analyzed by rewrite-rule tools, e.g., Reve [18]; the two-state predicates of Larch interfaces and thus, task predicates, can be analyzed by verification systems that support first-order reasoning, e.g., Gypsy, HDM, and FDM [9, 21,22]; formulae in real-time logic can be mechanically transformed into equivalent formulae in Presburger arithmetic. However, though many of these tools are available, much work is needed to integrate them so our specifications could be machine checked and analyzed.