EECS 219D
Contents

Home
Earlier offerings

Project

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.

Due Dates

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

Past Projects

Guidelines

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.

Project Suggestions

Below is an evolving list of project suggestions:

  1. 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.
  2. 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.
  3. Bounded Execution of PN Networks: Implement Geilen and Basten's bounded execution policy for PN.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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 that generates SMV specifications from SR/FSM models in Ptolemy II.
  9. 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.
  10. 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.
  11. 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.
  12. 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 languages.
  13. 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).
  14. 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.
  15. 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).
  16. 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).
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
You are not logged in 
Contact 
©2002-2017 U.C. Regents