A project is required for this course. A typical project will have an experimental component (software) backed by a paper describing the principles being investigated. For the experimental component, students are encouraged to use a common technology base in order to maximize the effectiveness of interaction within the group. Specifically, the technology base upon which students will normally be expected to build is:
- The Java programming language.
- The Ptolemy II framework.
- The Eclipse integrated development environment.
- 9/22: One page project proposal.
- 10/20: One page project status report due.
- 11/17: One page project status report due.
- 11/29: Project paper submission due.
- 12/6: Review of project papers due.
- 12/14: Project presentations.
- 12/16: Project papers due.
The paper component will be expected to be conference quality, with appropriately chosen and cited references to the literature. Papers must be scholarly, meaning that they describe original work, critically assess both the advantages and disadvantes of that work, and compare that work to other published work.
Papers should be no more than four pages in length,
two column format, as given by the
Latex template. Students are required to submit an extended abstract
for review by other students in the class. The extended abstract should
follow the same format as the paper, but can be shorter.
Below is an evolving list of project suggestions:
- Models for representing broadcast and multicast communication. The goal of this project is to implement broadcast and multicast communication in models of networked cyber-physical systems (CPS). The modeling environment used in this project is Ptolemy II. These communication mechanisms will allow for analysis of network latencies through simulation. In a first step, existing networks should be modeled. In a second step, smarter networks should be investigated that allow for deterministic communication in CPS.
- Code Generation for Discrete Event Controllers in Ptolemy II
The goal of this project is to provide a code generation framework for discrete event (DE) control models for cyber-physical systems (CPS) in Ptolemy II.
- Bounded Execution of PN Networks:
Implement Geilen and Basten's bounded execution policy for PN.
- Modular SR code generation:
Implement an SR scheduler based on Stavros Tripakis' idea of modular
code generation. For n outputs of a composite,
you need at worst n+1
functions to be called for the composite. An actor is given as a set
of functions and a dependence graph constraining the order in which
they can be invoked. These functions can share firings of internal
actors, but the generated code has to avoid re-firing actors that have
been fired before in the same cycle. The dependence graph can be
constructed using the causality analysis in Ptolemy II.
- Actor engineering:
The goal of this project will be to develop software engineering tools
specifically designed to facilitate the design of actors.
This could be, for example, in the form of an Eclipse plug-in,
leveraging the Eclipse representation of Java or C code to, for example,
perform static analysis of the actor code to determine and/or enforce
certain dataflow styles (e.g., to ensure that inputs to the actor
are consumed). Alternatively, the plug-in could serve as a
syntax-directed editor that is aware of the structure of
actor-oriented models and of coding conventions.
- 3-D modeling:
Define models in Ptolemy II for autonomous vehicles (rolling or flying) and
their interaction with 3-D terrain models. This will follow principles
similar to the wireless sensor network modeling in Ptolemy II, but
interactions between components will be through 3-D geometry models
and the laws of physics.
- Efficient hybrid systems simulation:
This project would leverage the causality interfaces in Ptolemy II
to vary step sizes throughout a model automatically. In particular,
hybrid systems introduce discrete transitions that, in a brute force
hybrid systems simulator, cause evaluation of all signals and disruption
of adaptive step size algorithms at the time of the transition.
This evaluation and disruption is not necessary for portions
of the model that have no causal dependence on the discrete transition.
See the work of Gautam Biswas and Xenofon Koutsoukos at Vanderbilt.
- Model checking:
To make model checking more accessible to system designers,
specify and prototype a tool that supports graphical specification
of safety properties in SR/FSM (i.e. Statecharts) models, and
then leverages model-checking tools to check those properties.
This project can build on a prototype tool created by Patrick Cheng
SMV specifications from SR/FSM models in Ptolemy II.
- Concurrent user interfaces:
Concurrency models for user interface design have been a mixed bags.
Attempts to use threads, as in Java, have failed miserably. Prevailing methods
are event based, but rather ad-hoc and unprincipled. An old but recently
enhanced event-based model of computation called Event Relationship
Graphs (ERG) seems to hold considerable promised to improve the situation.
This project would explore this idea.
- Design patterns:
Identify and categorize concurrent design patterns, and create
mechanisms based on model transformations and newly introduced design
pattern infrastructure in Ptolemy II to support construction and
combination of such patterns.
- Distributed autonomic computing:
Build a library of actors and design patterns for distributed health
management of executing concurrent models. As a simple example of an
application, the display case outside 337 Cory Hall, which runs
(largely untrusted) Ptolemy II models as demos. One or more other
Ptolemy II models, running on other machines, will interact with
the models running in the display case to monitor their health
(liveness, memory usage) and repair the models when necessary.
- Actor-oriented security models:
Study the problem of security in distributed actor-oriented models
and implement a security toolkit for building secure distributed models.
This project would build on concepts like capabilities and leverage the
fact that actor libraries can be more flexibly designed than programming
- Model-based refactoring:
Construct a model-based refactoring tool for actor-oriented designs.
This tool would require a formal description of a refactoring operation
(such as addition or removal of hierarchy) and would use that
description to guide execution of the refactoring operation.
This could build on the model transformation work of Thomas Feng
and/or on Alexander Wisspeintner's work in Manfred Broy's group
at TU Munich).
- Higher-order components:
Perform a study of the role of higher-order components in actor-oriented
design, and devise a coherent library of basic operations that are
required for expressiveness. This work can leverage various
higher-order components that have been implemented in Ptolemy II,
but should identify gaps in the capabilities and then fill those gaps,
and should identify higher-order components that operate at the abstract
syntax level and distinguish from those that depend on semantics.
The Ph.D. thesis of John Reekie could be very useful.
- Interfaces in actor-oriented design:
In principle, actor-oriented models can have more flexible hierarchies
where an actor interface is used in a model but multiple
implementations can be substituted. These multiple implementations
might be selected to vary the level of abstraction of the model or to optimize
against certain criteria. This project will implement a mechanism in
Ptolemy II that supports substitution of multiple implementations for
an interface. (cf. Vanderbilt's DESERT project).
- Clock calculus:
With the certification by European aviation authorities of SCADE for use in
safety critical aircraft control software, synchronous languages have been
getting more attention recently. This project will develop a deeper
understanding of the issues by constructing a Lustre-like clock calculus
for the Ptolemy II SR domain (Lustre is the language underlying SCADE).
- Actor languages:
Compare actor definitions languages Cal (from Berkeley) and StreamIT
(from MIT) for use in dataflow models (such as Ptolemy II SDF, DDF,
and PN). One possible outcome might be a variant of these languages,
for example one with a friendlier syntax that combines the strengths
of the two languages.
- Textual syntaxes for block diagrams:
Visual syntaxes for actor-oriented models have a certain appeal for
pedagogy, but many people feel that visual syntaxes will never scale
sufficiently to be able to deal with complex designs. This project
will explore textual syntaxes that are compact, readable, and
capable of expressing (at least) the Ptolemy II abstract syntax
for actor-oriented models.
- Static analysis of continuous-time models:
The theory of control systems has a rich set of formal analysis techniques
for continuous-time feedback systems. This project will develop analysis
tools that apply that theory to Ptolemy II models in the CT domain to
perform, for example, stability or robustness analyses.
- Resource sharing models:
Models of computation like Giotto, xGiotto, and Timed Multitasking
(the TM domain in Ptolemy II) manage a single shared resource, the
CPU, sharing it across several real-time tasks. The purpose of this
project is to devise a software architecture that augments this with
mechanisms for sharing multiple resources, and for performing timed
simulation of the resource sharing, formal analysis of the schedulability
of the shared resources, or both.
- Verification of dataflow models:
Boolean Dataflow (BDF) offers a rich formal analysis of consistency of
models. This can be used for verification by specifying safety
conditions in terms of consistency. This project will formulate
some verification questions this way and will apply implementations
of BDF to these.