The first two years of my Ph.D. have largely revolved around TickTalk , an NSF grant dedicated to developing timing APIs to simplify the development of federated, time-sensitive cyber physical systems.
Imagine a traffic management system, where sensors deployed on the ground sense vehicles passing. The traces of signal data could be analyzed to determine traffic composition, volume, etc., and aggregated to provide holistic flows of traffic movement in a city. The results would redefine how traffic lights, speed limits, and on-ramps actuate to redirect and smooth traffic flows. This is a distributed, heterogeneous, time-sensitive application, and TickTalk (and by extension, TTPython) aims to provide a language and runtime environment for these types of applications.
In the summer of 2021, I created the first major version of TickTalk Python (TTPython), a language and distributed runtime environment for distributed time-sensitive applications. The 0th version of this project was created by Bob Iannucci in February of 2021, and included the initial syntax and compiler. We used elements of this system in our submission to a CPS-IoT Week Student Design Competition, but the tools were not fully implemented at that point. During the summer, I fixed that.
TTPython
TTPython is a language, compiler, and distributed runtime environment that represents programs as dataflow graphs such that a singular 'macroprogram' can be broken into smaller pieces and run isolated on a device within a heterogeneous distributed system.
My work has been on the distributed runtime, so that devices can form a network and execute a time-sensitive, distributed application. I could speak at great length on the details and complexities of this. If anyone cares that much, I'll nudge you towards a Demo Video and the doc pages for the project, for which I developed/wrote about 85% of the content as of version 1.0.0. Whether it grows into something significant or not, time will tell, but plans are in place.
To me, the more intesting elements to work on were at the architectural level: defining what processes exist within a device and they interact, and defining how devices execute the distributed program.
For the former, I designed the devices (called "ensembles" for reasons unimportant here) to consist of a few intercommunicating processes, each entirely isolated and reading information through a singular input queue with self-describing messages (those familiar with lots of message-passing architectures, it was technically a Kahn Process Network). Each process would handle synchronizing inputs, executing graph nodes, or propagating outputs (and any other network management tasks), respectively; this was designed to match the abstractions included in each node of the graph (called "SQs" in TickTalk parlance). I'm very fond of this interprocess communicaiton model, and find it to be extensible and predictable.
For the latter point (on how the devices execute the distributed program), the main steady-state behavior was defined already by how the graph nodes sent outputs to one another. What wasn't covered was how the network of devices is configured so that the graph nodes are mapped to devices in the system and graph execution was started. In short, some management-level entity (a 'runtime manager' if you will) acts as a coordinator. Devices request to join, and the runtime manager verifies and accepts them, propagating networking information to those that already connected. When ready, it sends graph nodes to devices along with how they much send outputs to, and injects a few initial values to kickstart execution. At that point, the graph executes in a totally decentralized fashion (although outputs go back to that runtime manager for logging purposes). Altogether, pretty simple (and certainly has some obvious failure cases), but I was elated to find that I could use this formulation (and the other 5k lines of Python I developed) to execute a program across a server, laptop, and raspberry pi without any special tricks.
I ended my commitment to the TickTalk project at the end of Summer 2021, but I'll be sure to check back in periodically to see if/how the tools I developed see continued use in what is now an open source project under the MIT license.