DOC

Time Weaver

By Ashley Graham,2014-06-28 19:59
6 views 0
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

    http://www.cs.cmu.edu/~rtml

    RTML, Carnegie Mellon University ? 2001-2002

    This research is sponsored in part by the Defense Advanced Research Projects Agency under the Model-Based Integration of Embedded Software (MoBIES) program under a contract with the Air Force Research Laboratories.

    No part of this document should be interpreted as being endorsed by any part of the United States government or its agencies.

    Time Weaver 1.0 User Manual 1

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 ............................................................. 7 1.3. The CMU IMAGES Project .................................................................................. 9

    1.4. Organization of This Document ............................................................................ 9 1.5. Summary of Time Weaver Features and Capabilities ........................................... 9

    1.6. Current Status of Time Weaver ......................................................................... 10

    2. Main Concepts ................................................................................................................ 12

    2.1. Components ........................................................................................................ 17 2.2. Couplers ............................................................................................................. 17

    2.2.1. Typed Coupling Groups ..................................................................................... 18

    2.2.2. Aggregation ....................................................................................................... 19

    2.2.3. Timing Aggregation ........................................................................................... 20

    2.2.4. Coupling Mechanisms ........................................................................................ 20

    2.2.5. Coupling characterization................................................................................... 21

    2.2.6. Roles .................................................................................................................. 22

    2.2.7. Special couplers ................................................................................................. 22

    2.2.8. Scopes ............................................................................................................... 22

    3. The Time Weaver GUI................................................................................................... 23 3.1. Building Systems ................................................................................................ 24

    3.1.1. Configuring Components ................................................................................... 25

    3.1.2. Configuring Event Interfaces.............................................................................. 26

    3.1.3. Configuring State Managers and Protocol Agents .............................................. 26

    3.1.4. Configuring Couplers ......................................................................................... 26 4. Boeing OEP ACL Component ......................................................................................... 27 5. Generating Boeing OEP XML Configuration .................................................................. 29 6. Common Patterns ............................................................................................................ 30

    6.1.1. Active components ............................................................................................. 30 6.2. Invocation ........................................................................................................... 30 Time Weaver 1.0 User Manual 2

6.3. Event delivery ..................................................................................................... 30

6.4. Event merging .................................................................................................... 30

Time Weaver 1.0 User Manual 3

1. 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 1analysis tools developed by DARPA‟s MoBIES program.

    ; 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 2provided. Time Weaver 1.0 generates Real-Time Java and C+ code.

    ; 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.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.

1 See “http://www.darpa.mil/ito/research/mobies/index.html”.

    2 The C++ code-generation capability in Time Weaver 1.0 is not as mature as the Real-Time Java code.

    Time Weaver 1.0 User Manual 4

    ; 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.

    Track Radar Filter Display

    Figure 1. A radar system to track airborne objects.

1.1.1. An Example System

    As an example, consider the tracking system shown in Figure 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:

    Time Weaver 1.0 User Manual 5

    ; 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.

Radar Filter Track Display

    Processor Processor

     Assignment Assignment

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.

    Time Weaver 1.0 User Manual 6

    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. 1.2. A Sample Use-Sequence of Time Weaver

    A common usage sequence of the Time Weaver environment is illustrated in Figure 0 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 ?. This is to timing analysis into a schedulability analysis tool like TimeWiz

    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.

    Time Weaver 1.0 User Manual 7

    ?Rational Rose UML Time Weaver

    

    ;

    XML

     Repository Target

    

    

    

    TimeWizRT-Java/CORBA

    ?Windows/Linux-RK

    Figure 1. A Common Usage Sequence of the Time Weaver environment.

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

     3 The DARPA MoBIES program is developing a standard XML representation for embedded software systems

    called ESML (Embedded Systems Markup Language).. Time Weaver 1.0 User Manual 8

1.3. The CMU IMAGES Project

    Schedulability & QoS analysis UML QoS/Resourc Hybrid Systems Verification Timing models requirements constraints Test vector generation

    Reachability analysis State Control laws RT-CORBA machines

     Run-Time IMAGESPlumbing Linux/RK RT-Java Toolset

    Code Generation

    Run-Time Environment Embedded Target

    Measurements

    Multi-View Modeling + Analyses + Targeting Freedom +

    Reusable Embedded Software Components

     Figure 2. Goals of the IMAGES Project at Carnegie

    Mellon 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 4Carnegie Mellon University. The principal investigators 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 0.

    1.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.

1.5. Summary of Time Weaver Features and Capabilities

    It is a tool front-end for

     (a) building reusable embedded software components with components

     4 Professors Rajkumar and Krogh can be reached at raj@ece.cmu.edu and krogh@ece.cmu.edu respectively.

    Time Weaver 1.0 User Manual 9

     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

1.6. Current Status of Time Weaver

    Current constraint Cannot automatically reverse-engineer systems

    Time Weaver 1.0 User Manual 10

Report this document

For any questions or suggestions please email
cust-service@docsford.com