Part II project ideas

Some of these project ideas revolve around our component system, variously called SBus and PIRATES, which handles the transport of messages from producers to consumers. Some of these messages come in the form of a stream, a series of data that describe the state of the world at particular points in time.

Semi-obviously, I am interested in supervising students choosing to work on one of these ideas or who have an interesting one of their own. Ask me!

Congestion visualisation

Systems such as SCOOT produce data that can be used to estimate the current level of congestion. Often the most natural expression of these data has no geographical meaning, e.g., SCOOT reports things like queue lengths in Link Profile Units or LPUs. How should such data be presented to the user so as to maximise meaning and minimise false precision which may be misleading? To what extent should the display method depend on the characteristics of the underlying sensors? How should these two things be coupled?

Component language bindings

SBus/PIRATES is implemented in C++ and language support for components that are also written in C++ is good. The design allows for the construction of other language bindings with relative ease. However, care must be taken to present an interface that is natural to each language in question—not everything sees the world as C++ does. What would good language bindings look like for Python? Ruby? D? Prolog? Haskell? Ocaml? What about something like JavaScript; would a proxy (perhaps using XMLRPC) be required?

Telephony applications

The web and mobile phones are obvious user interfaces for applications that process and present data originating from SBus components. What about the telephone? A simple application would be where dialing a number told you the next bus departure. What facilities would be nice for authors of such applications? How can this best be integrated into a PBX like Asterisk?

Stream storage

Often streams from sensors must be stored for later perusal or processing. How should this be done? What sort of queries (e.g., “send me the temperature from 01:03:47 through to 07:13:58”) make sense? Should the reply contain all the data at once or should it be a form of replay?

Data filters

Sensors are unreliable and streams of data from them may have holes or periods where the quality is reduced. Sometimes the data may be correct but not very useful. For example, counts of vehicles may be less interesting than rates.

One could imagine a useful toolbox of components that do processing on streams without knowing (or caring) about their meaning. Examples include differentiators, integrators, something to compute averages, filters, and so on. Can you think of—and build!—these and other useful tools?

Prolog on FPGAs

Prolog is an appealing abstraction for all sorts of programming problems and the Warren Abstract Machine (WAM) is an effective way to implement it. Write a WAM in Verilog that will run on FPGAs. The idea is mildly crazy because it seems so wrong, but for things like network flow classification or pattern detection in security systems, this could be just the tool.