Time Weaver



Time Weaver 1.0

User’s Manual

Real-Time and Multimedia Systems Laboratory (RTML)

Departments of Electrical and Computer Engineering and of Computer Science

Carnegie Mellon University



RTML, Carnegie Mellon University © 2001-2002

Table of Contents

1. What is Time Weaver? 4

1.1. A High-Level Overview of Time Weaver 4

1.1.1. An Example System 5

1.2. A Sample Use-Sequence of Time Weaver 6

1.3. The CMU IMAGES Project 8

1.4. Organization of This Document 8

1.5. Summary of Time Weaver Features and Capabilities 9

1.6. Current Status of Time Weaver 10

2. Main Concepts 11

2.1. Components 16

2.2. Couplers 16

2.2.1. Typed Coupling Groups 17

2.2.2. Aggregation 18

2.2.3. Timing Aggregation 19

2.2.4. Coupling Mechanisms 19

2.2.5. Coupling characterization 20

2.2.6. Roles 20

2.2.7. Special couplers 21

2.2.8. Scopes 21

3. The Time Weaver GUI 22

3.1. Building Systems 23

3.1.1. Configuring Components 24

3.1.2. Configuring Event Interfaces 25

3.1.3. Configuring State Managers and Protocol Agents 25

3.1.4. Configuring Couplers 25

4. Boeing OEP ACL Component 26

5. Generating Boeing OEP XML Configuration 28

6. Common Patterns 29

6.1.1. Active components 29

6.2. Invocation 29

6.3. Event delivery 29

6.4. Event merging 29

What is Time Weaver?

Time Weaver is a comprehensive framework and tool for the creation and management of reusable software components, and is specifically targeted at the domain of embedded and distributed real-time systems. The framework used is called the “Coupler” framework, and is based on the notion of port-based software components. The framework is augmented by a graphical user interface (called Time Weaver) that is written in Java and can therefore be run on any platform that supports Java.

Time Weaver also has a host of other complementary functionalities:

• XML Data Interchange: Time Weaver represents its data using XML (eXtensible Markup Language), and therefore is intended to interface with multiple modeling and analysis tools developed by DARPA’s MoBIES program[1].

• Interfacing with UML: Time Weaver can import UML (Unified Modeling Language) class diagrams. Currently, Rational Rose is the only UML tool that is directly supported.

• End-to-End Timing Analysis: Time Weaver can export timing information from its components to a timing analysis tool like TimeWiz® to perform process-to-processor binding and end-to-end schedulability analysis.

• Code Generation: Time Weaver can generate runnable code from the information provided. Time Weaver 1.0 generates Real-Time Java and C+ code[2].

• Configuration Generation: Time Weaver can generate XML representations of complete system configurations.

Any or all of these complementary functionalities of Time Weaver may be optionally skipped. In other words, it is not required that a user exploit all the functionality supported by the tool. For example, the MoBIES Boeing Open Experimental Platform project intends to use the configuration generation capability, but completely skip the code-generation capability. Others may not use UML diagramming tools at all as an input to Time Weaver, and instead choose to represent their component relationships directly in Time Weaver.

1 A High-Level Overview of Time Weaver

Consider an embedded real-time system. The development of this system consists of two coarse-grained but distinct aspects:

• Functional Design: The first aspect deals with the development of application-specific logic and functionality, where code corresponding to the specific needs of the application(s) at hand, must be designed and developed. The application logic of any relatively large system is typically contained in several modules. We refer to this as the functional design of the system.

• Deployment Design: The second aspect of the system corresponds to how the various modules comprising the application-specific logic communicate and interact with one another. This aspect also involves decisions about what processors, operating systems and middleware layers to use. After these choices, the application-logic modules need to be “mapped” to these processors and their systems software layers.

The premise of Time Weaver is that the functional and deployment designs can be cleanly separated, and that this separation enables the use of reusable software components in embedded real-time systems. Time Weaver then aims at automating the deployment design aspect without requiring any human coding while offering the user extensive flexibility in tailoring attributes of the deployment but at much higher levels of abstraction. Time Weaver therefore promises significant benefits in software productivity. In addition, by enabling and interfacing with a host of modeling, analysis and simulation tools, the veracity and correctness of the final system can be verified before actual deployment.

In other words, application-specific logic and computational modules are created as elements of a component library, and can consist of signal processing operations such as video processing and speech recognition, command and control operations, mathematical transformations, data predictions, or control loops.

[pic]

1 An Example System

As an example, consider the tracking system shown in Figure 1 which tracks airborne objects using radar. A radar front-end receives echoes of emitted signals from the sky and passes them to a filter. The filter removes from these signals noise and information about static objects and perhaps uninteresting objects such as birds. The filtered signals are then mapped to known tracks (or new tracks are created) of flying objects, by the tracking subsystem. Finally, the various tracks are shown on one or more display screens. Frequently, end-to-end timing constraints (of a few seconds or less) are associated between the instants of signal reception at the radar and its corresponding display on the screen of an operator or user.

The functional design of this system involves the design and development of these four modules to perform their specific functions corresponding to the partitioning of the application functionality. Each of these functions can (and must!) be coded as re-usable software components, where each software component transforms its input data into some other form of output data.

The deployment design of the system must determine the answers, for example, to the following questions:

• How these software components communicate with one another, which in turn can depend on whether they run within the same process, the same processor or on different processors?

• How to distribute load across the processors in the system (assuming more than one)?

• How to ensure that the system can be made reliable, and tolerate one or more points of failures?

• How to reduce end-to-end latencies in case the end-to-end timing constraints are not satisfied?

• How to verify the behavior of the deployed application vis-à-vis timing, liveness, and fault recovery?

• How to build and manage the binary configurations that must be downloaded to the various system processors?

The objectives of Time Weaver are to enable developers

• to make different decisions on any or all of these questions freely and flexibly (as a given system evolves or for different systems),

• to automate the impact of these decisions both in terms of correctness and glue-code generation, and

• to “componentize” applications for future re-use (and customization).

For example, in this radar system example, the designer may initially choose the following processor binding of its four components.

[pic]

Later, if the designer chooses to move the “Display” component to a separate processor, it is just done by changing the component’s “BoundProcessor” attribute. As can be guessed, these 4 components can be bound to 1, 2, 3 or 4 processors in a large number of combinations. For each of these processor binding choices, these components may need to communicate across processors, across different processes in the same processor, and across different threads in the same process and processor. The inter-process(or) communications (IPC) code that is needed to make these components interact with one another will automatically be generated and optimized by Time Weaver. If components are moved into the same processor and can exist within the same process, the IPC code can be automatically replaced by highly efficient accesses to global variables.

One might ask “What middleware layer (such as CORBA, RMI, DCOM and .NET) does Time Weaver subscribe to?”. The answer is “None, Time Weaver is neutral and can in principle work with any middleware service since the middleware used is abstracted away from the user.

Thus, Time Weaver is a framework and tool with which a designer/developer can

• create reusable embedded software components for distributed and embedded real-time systems,

• capture, analyze, and optimize non-functional aspects,

• optimize inter-process communications and degree of concurrency,

• customize component parameters (in particular timing parameters),

• represent and manipulate data path, control path and timing paths independently,

• generate fully functional target code by linking with functional code segments.

2 A Sample Use-Sequence of Time Weaver

A common usage sequence of the Time Weaver environment is illustrated in Figure 2 and is as follows.

• In Step 1, UML class diagrams are imported from a UML modeling tool (such as Rational Rose) into Time Weaver.

• In Step 2, the developer using the Time Weaver GUI adds components to the Time Weaver project from a component library, or creates components from scratch. (More information on these features will be provided shortly). Interactions and “couplings” among these components will also likely be added. Information regarding the number of execution threads in the system, timing parameters and data flows in the system is also added.

• In Step 3, this Time Weaver project is then exported for performing end-to-end timing analysis into a schedulability analysis tool like TimeWiz®. This is to ensure that the software configuration of the software components in Time Weaver will satisfy their timing constraints when deployed on a hardware platform of interest.

• In Step 4, the results of the timing analysis are exported back to the Time Weaver project.

• In Step 5, Time Weaver is used to generate code that can be run within a target environment.

[pic]

It is worthy to note that the data exchanges between Time Weaver and other tools use an XML representation format.[3]

3 The CMU IMAGES Project

[pic] The Time Weaver tool is being developed by a DARPA MoBIES-funded project called IMAGES (Integrated Modeling for the Analysis and Generation of Embedded Software) at Carnegie Mellon University. The principal investigators[4] of the project are Prof. Raj Rajkumar and Prof. Bruce Krogh. A visual description of the goals of the IMAGES project is provided in Figure 3.

4 Organization of This Document

The rest of this document is organized as follows. Section 2 describes the main concepts and primitives used within Time Weaver. It also illustrates how a simple embedded real-time system can be modeled in Time Weaver. Section 3 describes the graphical user-interface of Time Weaver.

5 Summary of Time Weaver Features and Capabilities

It is a tool front-end for

(a) building reusable embedded software components with components

only providing "application-specific" logic

* basic component descriptions can be imported from tools like

Rational Rose

- we want to interface Time Weaver later with Matlab as well

* components can be aggregated to create larger and larger components

* the tool allows the separation of the following in terms of independent manipulation, analysis and optimization:

(i) control paths: how many threads/processes exist, and whether a component has a built-in thread (a so-called active component), or can be invoked by multiple threads (a so-called passive component). With data-sharing across components/threads, mutual exclusion requirements and related requirements can also be specified.

(ii) data paths: threads/processes represent control paths, but data values may "flow" independent of those threads.

This is particularly explicit in Boeing's publish/subscribe architecture. Their "published" events indicate that data values have changed (and are a part of control flow).

In response to such a received event, a subscribed client can on its own volition check the new data value (affecting data flow). I/O can also be chosen to be blocking (wait until input is available), or non-blocking (continue if input is not available immediately).

(iii) timing paths: the periodicity of components are specified parametrically; so, a reusable component can be deployed at different rates by different developers. Since components can be aggregated, the periods of descendant components can be automatically set by setting the period of its parent component. By changing the period of *one* "root" component, the periods of a large number of child components can therefore be changed (using some algebraic relationship, like same as parent, twice that of parent, 4 times that of parent, etc.)

• the separation of the application-specific logic from its interfacing to the rest of the system is accomplished by

6 Current Status of Time Weaver

|Current constraint |Cannot automatically reverse-engineer systems |

|Tool inputs |Rational Rose UML Diagrams (class diagram and sequence diagrams) |

|Tool outputs |TimeWiz hardware & software configuration diagrams |

| |Generated code that can run on real-time OS targets |

|Meta-model |Port-based objects for inter-component communications |

| |Components can be composed from components |

| |All inter-component communications happen through “Couplers” |

| |Components can have application agents (for functional behavior), state agent and |

| |protocol agent. |

|Tools interfaced using XML |Rational Rose, TimeWiz, Teknowledge UML Interface |

| |Later, Boeing configurator using XML |

|Non-MoBIES technologies |Real-Time CORBA, OSEK |

Main Concepts

Terms and Definitions

Requirements

Rose exports:

compononent info

component type

set of receptacles (calling points)

set of facets (set of methods that can be called - called points)

events (Boeing model: CORBA events) - no types in Rose

TimeWeaver imports Rose info

Rose components become simple TimeWeaver components

events are occurrences which can be communicated across components, and

data may be associated with events (as opposed to RT-CORBA events)

user adds event types and interfaces

one interface per event type

(Dio's event-interface: an object that represents the event type)

model communication paths between components through couplers

aggregate components and components if necessary to create aggregated

components

configurator

a component has elements like an application agent, state manager, protocol

manager. The application agent corresponds to the component's identity

(self - corresponds to "this" in OO systems).

one application agent inside each component

zero or more ports inside each components: communication points with other

components (always through a coupler)

every port has one interface; a port can be an input port or an output port;

an input port consumes an event; an output port generates an event.

one or more state managers per port: a state manager can (1) perform

transformations (including the null transformation) to the data

associated with the events it is connected to, (2) controls delivery

of events to the application agent (e.g. mutual exclusion, wait

for any/multiple/all events).

one protocol manager per port: a protocol manager is the element responsible

for receiving/propagating events through a port to other components (e.g.

using TCP, UDP, multicast, CORBA events, etc.)

coupler types:

(software) couplers: design-time glue that represents run-time interactions

across/among components, can be bound to resource couplers defined

below.

resource couplers: processing resources and network links

processing resource couplers

network resource couplers

system: special resource coupler which contains the set of nodes and network

links with.

a coupler has an element called 'self' (corresponding to 'this')

a coupler can have zero or more roles, where a role represents the

interaction function of the event port attached to it. [And if a coupler

has one single trivial role, it may sometimes be eliminated and not

be visible.]

a coupler can have zero or one state manager per role. If the coupler has

one single implicit role (which is not visible), its state manager may

exist, be visible and be connected to the coupler's "self".

Within a component, there is one dispatch table per application agent and one

per state manager

dispatch table controls/specifies the mapping between input ports and

output ports (with null input or null output ports allowed);

i.e. it maps from one event interface to a set of output event interfaces.

- zero or more entries in each dispatch table

- each entry has one input event, one output event (can have entries

with duplicate input events or duplciate output events) and message size.

A protocol agent can be in the system coupler and a network resource coupler.

dispatch table for application agent may need to have an 'escape

hatch' to deal with complex logic which may be outside the modeling

environment.

dispatch table for the state manager may need to deal with failure conditions:

(1) add a row to represent the failure condition of any state like a timeout

(2) add 'initial state' and 'final state' attributes to each valid state entry.

Component Properties

Name

Timing path properties:

Period

Computation/Bandwidth requirements

Deadline

(Jitter)

Active/Passive

WaitForData for all input ports (should this be port-specific)

(ParentSynchronous):

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download